Tuesday, May 4, 2010

TDD is definitely one of the most controversial techniques that the IT industry has. Someone thinks it's really good, someone thinks it's really bad. Someone thinks it's a development technique, someone thinks it's a design one. So, I want now to share my view on the matter: TDD is for me a development technique, not a design one (unless you can accept bad design).

The best team I've worked in decided, in the beginning of the project, to use a full TDD approach. Tests were written before coding (both unit and acceptance tests), things were considered done when all tests passed and so on. But every time, for every single feature we had, we ended up reverse engineering a class diagram out of the code, and every time we realized that the design was simply bad. Responsibilities were in wrong places and the contracts were, at least, fuzzy. So what we did was planning big refactorings on those class diagrams and then execute them (of course, also the test cases had to be refactored). If my memory is good, we had 5 major architectural changes during the project, as you can see, a lot of rework.

Could that rework be eliminated? Well, most likely eliminated no, but drastically reduced yes. I believe that with a 1 hour architectural planning session right after sprint planning (we were working in scrum with 2 weeks sprints) we could have produced software with the same amount of quality but with much less rework (which is a thing that customers are never happy to pay).

Will something like that always happen when doing TDD? My answer is yes. TDD has a big flaw: it forces all the focus to the single unit under work (in most of the cases, one class), but it leaves the iteractions with other units in the system out (and eventually, all the "big picture"). The main benefits that planning sessions would bring in are that the entire team would be forced to look at the big picture and that the contracts between different units would be defined before starting coding them.

Last but not least, how can someone who calls him/herself a developer accept that the design of his/her software is done by some tests (which are just other pieces of software)?!?