Ruby-debug is awesome and always TDDin is dumb
Filed under: Software | 1 Comment »http://gilesbowkett.blogspot.com/2007/10/debugger-support-considered-harmful.html
I really like Giles and his blog, but I disagree on this point. I also get what he’s saying. When your doing TDD, it’s a lot easier to find the point of failure because you are coding incrementally. Red, Green, Refactor. If you hit an error in the “refactor” point then it’s easy to see where because you just made a tiny change.
However, I don’t always TDD. I don’t agree with the idea that every code needs a test that goes along with it. At a certain point you have to decide which tests are worth your time and which aren’t. Also, most people agree that 100% test coverage is a waste of time which backs me up. With a lot of code, you would have to write 10x as much code in tests to cover all the possible different permutations of the code you just wrote.
So there you go: you don’t have tests for everything. So when you have a bug you are trying to fix, how do you narrow down what’s causing it? At that point, you have 2 choices. Logger statements, or ruby-debug. And I find ruby-debug to be a much quicker and more interesting to way to see what’s going on with the code than using puts statements. There are times when puts statements are faster…but usually not.
That said, I agree with the general idea that we should test first and debug later.
Related posts:

I am a fan of unit testing (which I think of as white-box testing) and integration testing (which I think of as black-box testing).
As for TDD, I have come across situtations it is much easier for me to let the computer generate the computation and I verify afterwards that it is correct.
The specific example I have run across is verifying trace output of a program, e.g. that first there is a call event on line x, then a statement event on line y, and then a return event on line z and so on.
But here would be another example. Suppose I want to write a program that looks for Mersienne Primes. Here is another case where it is easy to verify the correctness of an answer but a pain for me to do the math beforehand.