Saturday 9 October 2010

TDD is great for some project, but in many it gives just a false feeling that errors are under control

Comments following "Agile Ruined My Life" post

TDD is great, for SOME things. In other cases it can just add hassle and has the danger of providing a false sense of security. If I come across a project that does nothing but TDD and sees that as the only validation of their work that is necessary (this happens very often) I can pretty much guarantee I can find higher level functional, flow and integration cases that break the carefully constructed classes.



TDD is good for braindead simple crap programming where you have a well defined set of requirements and need to slog through them. I used it today when I needed to write about 30 java classes to fill in the functionality of an app I had built. That allowed me to both ensure that I had all the details working and test the framework itself and ensure it did everything I intended it to do correctly.

Now the core of the app itself involved juggling about 50 complex files at the speed of vim with multiple teardowns and rewrites over the course of a few days. Lots of experimentation and learning. Any tests that I would have written would have broken irreparably within minutes. It was a purely creative endeavor. You cannot do that with TDD and if you try you will spend weeks refactoring tests and not seeing the forest for the trees.
By far the best thing TDD has brought to the table is test frameworks though. Having a nice place to throw all your throwaway assertions on acid is awesome and really does add to the confidence level even if it affirms that you just broke an assumption you intended to break.



TDD - is a very popular technique nowadays. Unfortunately there is very little number of tools that are universal. Therefore it is necessary to clearly identify for yourself - where the tool should be used and can save a project from failure and where appliing the tool can be either pointless or even harmfull.

No comments: