Thanks for sharing!

I apply TDD as often as I feel it fits. Sometimes when I’m spiking, unit tests help, sometimes they don’t.

And of course, please do not forget that TDD is a design activity not a testing activity. Of course you would not TDD a spike because you are not designing. When writing production code, you want to TDD because you want the design to be the best it can be given the knowledge of the system you currently have.

Perhaps this is why I have trouble swallowing unit testing or extreme programming or other best practices as the law. I guess there’s a place for these tricks (the work place,) but they do not speak to the pure form of hacking for hacking’s sake, which I so ardently defend! Unit testing, in particular, is designed to reel in spontaneous hacking. It is like framing a picture before it has been painted. Hacking, at heart, will continue to be something of spontaneous order, something of anarchy, and the landscape of hacking is something which comes from human action but is not of human design.

http://hackety.org/2007/12/24/thisHackWasNotProperlyPlanned.html

During Experimentation a test harness is just a nice place to put my code to and also it is easy to extract small sub-experiments into the separate “tests”.

Though I might be biased, because my platform used to be Symbian, where it is quite difficult to write “just an experiment” without supporting framework.

However, getting programmers to try TDD can be a big difficulty. Basically, you are asking them to do double the work (at least) to finish each job. Now this does not take into account that TDD is not the same as ‘unit testing’ as more complex designs can be built as each layer of the solution is built and tested to be built upon. The problem is that ‘Joe Developer’ isn’t interested in building code of this quality, he’s going to be using unit testing to ‘prove’ his code works so he can say ‘hey, my unit tests worked.’

I have not yet managed to convince anyone who is not interested in that degree of quality of the benefits of TDD. Also, these are the programmers who will be tempted to use the exploratory code as production code, rather then taking a good look over it and trying to recode it in a more efficient manner.

Lets face it, theres usually a big difference between developers who started before the .com era when being a developer was a geeky job and was learned in the Maths faculty, and those who did IT degrees in the business faculty and are strictly 9-5ers… who are looking to just get by on the minimum amount of work required.