Software engineering blog of Clément Bouillier

On wednesday March, 25th, we have a meeting on TDD at Alt.NET France. It was animated by two Octo consultants, Frédéric Schäfer and Djamel Zouaoui. Again, we reach a new assistance record, around 30 people.

You can find a more detailed minutes I wrote in French on Alt.NET France site. I give here a quick synthesis of the conclusion I take from this meeting.

The presentation started with an overview on why testing or why not testing? The discussion raises a lot of stereotypes : "longer", "more expensive", "I'll make them later" (=never ;)) and so on...

Then we get to when testing is useful (and indeed more or less why) :

• get code that just reveals developer intention (not more),
  
• test at the right granularity,
  
• protect yourself against inevitable application changes (regression),
  
• loss of time in repetitive debugging and other test console applications which are not reusable.

Frédéric and Djamel presented some code samples around MasterMind game to underline how to apply TDD. Main points were :

• make test first else you never will...
  
• make simple test first, and increment complexity step by step,
  
• don't try to conceptualize/develop the perfect thing on first try (let iterations drive you to the most accurate design),
• use some UML diagrams to guide your global intention but do not lose yourself in details,
• use the following virtuous circle : intention > test code (do not compile) > code to compile test code that fails the test (red test) > code that passes the test (green) > refactor (your code or your tests, not both in the same iteration)
• write test correctly = AAA : Actor, Act, Assertions (be careful of tests without assertions)
• a declared bug needs a test to ensure its correction
• always run all the tests (which should be automatic and fast)

Finally, we get to deeper subjects, and I conclude that TDD is a practice that lead developers to a set of well-known and good design practices :

• Apply patterns : dependency injection, GoF, M-V-VM for WPF was some of the examples, DDD...
  
• Use mocks/stubs to isolate tested objects,
• Continuous integration : to build and run tests continuously (and much more...),
• Code coverage : beware of 100% coverage illusion, it does mean that your code is perfect because of entry data combinations problem.

I was already convienced with TDD, but I think I get a more precise vision of it now. To conclude, I think TDD brings :

• code documentation (executable specifications),
• protection againts regressions and during refactoring,
• accurate and flexible design for your code.
  

Thanks again to Octo company, Frédéric and Djamel for hosting and organizing this meeting.