The Debugger is useless.
Cyrus says he doesn't need a debugger when developing managed code. He is not advocating using printf here. He is claiming that with TDD (Test Driven Development) most of his bugs can be resolved by "sitting and mulling on it" and having a "gestalt flash".
I half believe this. I expect that using TDD you should be able to get the code you are writing to do what you want by 'gestalting' rather than using a debugger. I am more skeptical that the bugs found by a QA department will be as simple to diagnose via 'gestalt flash'. Am I being overly skeptical here? Are there people out there with large scale TDD experience that can back up Cyrus? I don't believe anyone has said unit testing removes all bugs or obviates the need for QA, so you will get bugs. Unless you actually prove the correctness of your code it does have bugs.
I think that TDD helps provide a mental model as you code first the test, then the implementation. That stronger mental model creates a perception that stepping through newly written code with a debugger won't provide any new or useful infomation. However, when diagnosing a problem in foreign code do TDD developers go to the unit tests first? Does a large, unfamilar, set of correctly running tests provide useful insight about what's wrong?
Comments
- Anonymous
June 10, 2004
I disagree.
I agree that TDD does encourage the developer to create testable code. I have done large developments using TDD approach and find that the Debugger is still an essential tool in the developers arsenal.
If you have the tools to allow you to step through code and evaluate variables why not use it! - Anonymous
June 10, 2004
Steve,
>
Does a large, unfamilar, set of correctly running tests provide useful insight about what's wrong?
>
Absolutely! By running and creating tests first, you understand the system better and better. It helps test assumptions. You determine what the desired outcome is, test it, see if your assumption was correct or not, and refactor your test accordingly. In the end, you have a much better understanding of the foreign code, as well as a base set of tests to use while refactoring the foreign code.
As for involvement of QA, that need is never removed with TDD. Instead, I believe, it enhances the work the two groups (QA and development) do together. Typically, when you get a bug from QA, you have to reproduce it. What I do immediately is write a new test, listing the desired outcome that is mentioned in the bug report. Then I test, see it fail, refactor my code, and keep doing this until the test passes. Now, I have a test I can run all the time to make sure this QA test case runs correctly, because I know they will be checking it as well.
So, again, I don't see TDD as a replacement for QA. These are two parts of the whole. All software is made up of the minute details (classes, methods) and the bigger picture (functionality, requirements). Both TDD and QA help meet these needs. - Anonymous
June 10, 2004
Also, the debugger is not useless, because there are times that you need to step through code, but I find it rare these days:
http://weblogs.asp.net/rhurlbut/archive/2004/05/28/143913.aspx - Anonymous
June 11, 2004
If you do TDD, you end up with decoupled code. That means that adding a test for something is specific. When your QA or user sends you a bug report, you can do Test-Driven Debugging instead of firing up a real debugger.
http://blogs.msdn.com/jaybaz_ms/archive/2004/06/07/150602.aspx
The debugging process is faster this way, and at the end you can be confident that
1) You fixed the bug
2) You didn't create a regression
3) This issue will never regress in the future.
If you don't have well-factored code with unit tests, retrofitting them is extremely difficult. It's hard to understand why TDD works when you only work with legacy code. - Anonymous
June 11, 2004
Andrew - I'm 100% on board with you. My use of "The debugger is useless" was meant to be ironic. :-) Also despite my general skepticism of TDD being a panacea I am fully onboard with it in spirit. As Jay mentions above I work almost exclusively in code that was not written TDD, and retrofitting C++ code to be TDD would be quite a task. - Anonymous
June 11, 2004
Robert - I agree that adding tests to unfamilar code will provide a better mental model. However, when you need to diagnose a problem in someone else's code, their test suite is another large unfamilar code base. I would think going to a debugger is likely to be more efficient in that case. - Anonymous
June 11, 2004
Jay - I've fixed the wrong bug before by making up my own repro and fixing that instead of what the QA gave me. How can you be sure you are attacking the right problem before you diagnose it? What if the problem isn't in your code? Shouldn't your responsibility be to reduce the latency of getting that bug to the right person? - Anonymous
June 13, 2004
Steve -- That makes sense regarding some initial use of the debugger in that particular case. But, it seems to me, as you become more familiar with the code AND the test suite, you may need the debugger less and less. As with all things, you use the tools that fit the problem.
For me, the use of the debugger vs. TDD has always been the issue of potentially losing your test case as you step through a debugger, looking at values, and tweaking, versus saving your test cases in a test suite. After you are finished debugging, you may not have the values you used to test your assumptions.
When I do use a debugger, I use both worlds. I let the test case drive my test values, and then watch the results through the debugger. If I find issues, I don't just change values in the debugger, but instead note them in the test case, or create a brand new test case, and restart the process. This way, I am doing both: debugging code, plus keeping a record of the actual test cases I worked on. - Anonymous
July 12, 2004
The comment has been removed - Anonymous
June 07, 2009
PingBack from http://weakbladder.info/story.php?id=5754