I love TDD (test driven development), only problem is I don’t think that way. And also feel that it makes you write more unit test than required. Anyways … (web is filled with holy wars on to do TDD or not, so let’s not get into it)
But the other end of TDD is (what I call) “Debug Driven Development”
or DDD.
Basically developers tend to write a line of code then test
it using a run time debug after putting breakpoint, to see if everything is
working fine till that point.
I am not totally against this technique, scenarios when
there is complicated peace of logic or data structure which is difficult to
visualize using static code analysis. But doing it too much is criminal, especially
in the cases where
- debug environment is complicated
- time to reach the debug point is too far in the flow or is slow otherwise
Writing a complicated piece of code and testing if you are
on right path, is so easy using a unit test (even without TDD). I have saved
hours doing so.
And then not just time, using too much debug just tells that:
- you just want to make the code work without thinking if it’s a good design,
- no thoughts on if it’s maintainable,
- no thoughts on if there is a better way of doing it,
- and most of the time there was no design to start with.
So take a small piece of advice – please don’t use runtime debugging
just to write code.
