3 ms·

Nope. It is absolutely false. You will always need a debugger and there are some problems that are not unit testable at all. How do you unit test a random WPF b

Nope. It is absolutely false. You will always need a debugger and there are some problems that are not unit testable at all. How do you unit test a random WPF bug? And you'll always need a fancy code editor unless you're masochist.

pjmlp 10y ago
Go doesn't have yet anything capable of matching WPF and Blend.
pmarreck 10y ago
If WPF was designed from the get-go using TDD, there would be less of a problem here in this case. I myself have hardly ever needed a debugger in any code i've worked on that has been TDD from the ground up. And it is almost ALWAYS related to OTHER code that was clearly not written with TDD in mind. Tell me something: What exactly is a "bug"? It is literally just a state the programmer did not expect, correct? So how do you keep all states expected? By constraining them (types, guards, etc.), by testing them in the small (unit testing, TDD), and by making them (ideally) immutable values (preventing unexpected changes to values within one stack frame). If you can control all possible states in the small, you can largely eliminate bugs in the large. At least, I've found this to be the case after 20 years of working on procedural and OO code...
- pjmlp 10y ago
  I am yet to see TDD work with native GUIs.
  - pmarreck 10y ago
    http://stackoverflow.com/questions/382946/how-to-apply-test-driven-development-for-gui-applicationvc-mfc http://stackoverflow.com/questions/382946/how-to-apply-test-... It's possible, and it works. Read the topvoted comment there and follow its links.
    - pjmlp 10y ago
      "This approach removes the GUI layer from TDD and unit testing. It does not mean the GUI is never tested but just acknowledges that it is not cost effective to pursue automated GUI testing, particularly as part of TDD. Integration and user testing should cover the GUI." Hence, not tested at all via TDD.
skj 10y ago
I'm not going to say categorically that you never need a debugger... But, I've been working with Go for years and have never used a debugger. I don't feel like I'm missing out on anything.

pjmlp 10y ago

Go doesn't have yet anything capable of matching WPF and Blend.

pmarreck 10y ago

If WPF was designed from the get-go using TDD, there would be less of a problem here in this case. I myself have hardly ever needed a debugger in any code i've worked on that has been TDD from the ground up. And it is almost ALWAYS related to OTHER code that was clearly not written with TDD in mind. Tell me something: What exactly is a "bug"? It is literally just a state the programmer did not expect, correct? So how do you keep all states expected? By constraining them (types, guards, etc.), by testing them in the small (unit testing, TDD), and by making them (ideally) immutable values (preventing unexpected changes to values within one stack frame). If you can control all possible states in the small, you can largely eliminate bugs in the large. At least, I've found this to be the case after 20 years of working on procedural and OO code...

pjmlp 10y ago
I am yet to see TDD work with native GUIs.
- pmarreck 10y ago
  http://stackoverflow.com/questions/382946/how-to-apply-test-driven-development-for-gui-applicationvc-mfc http://stackoverflow.com/questions/382946/how-to-apply-test-... It's possible, and it works. Read the topvoted comment there and follow its links.
  - pjmlp 10y ago
    "This approach removes the GUI layer from TDD and unit testing. It does not mean the GUI is never tested but just acknowledges that it is not cost effective to pursue automated GUI testing, particularly as part of TDD. Integration and user testing should cover the GUI." Hence, not tested at all via TDD.

skj 10y ago

I'm not going to say categorically that you never need a debugger... But, I've been working with Go for years and have never used a debugger. I don't feel like I'm missing out on anything.