CITCON Europe last weekend proved again to be one of the best conferences for networking and keeping up with the developments in the community. The most important session for me personally was “Beyond Basic TDD”, an openspace discussion on the topics that people with a few years of TDD experience should learn to take the next step. Here are the ideas we discussed:

(As with any other openspace discussion it is sometimes hard to capture who came up with what idea, so some parts of this post will be relatively anonymous.)

The discussion was kicked off by a case study from one of the participants who complained that his evolutionary design process failed to capture the model elegantly, which was probably due to focusing on testing methods, not describing activities/features, and not refactoring enough. Ivan Moore suggested refactoring mercilessly as a solution. This led to a discussion about Kent Beck’s Four rules of simple code, which which we paraphrased as:

  • express intent
  • remove duplication
  • use the smallest amount of source possible

(the fourth rule “runs all the tests” was not mentioned because it really is a basic thing).

As ways to teach people to express intent, we discussed writing assertions first when writing unit tests and asking people to explain what their test does and rephrasing it using those words. Steve Freeman said that it is very important to name features described in the name of the test method. Someone else suggested that bdd style naming (as in should do something) is good to drive intent-revealing tests.

We also discussed not getting tied up with the current design (which is probably a reflection of the DDD idea that there are always multiple models). Some practical techniques to show that are:

  • write code in test methods first, then refactor it out, to be able to experiment more freely
  • reverse refactoring, go back after a change and see if the code has really improved
  • delete and reimplement, time box changes but don't commit after the first implementation - revert the changes and try again to see if the solution will be different.

Another important idea we discussed was working in small steps, and Paul Julius suggested that he now stops every 15 minutes and if he is not ready to commit discusses with his pair why not. Someone else suggested an exercise where several pairs work on the same code which will incentivise people to commit often to avoid merge conflicts (if someone else commits before you, you’ll have to merge the changes).

The last very important take-away for me from this session was organising coding dojos to experiment with real code. Many participants said that most these ideas have to be experienced and seen in practice in order for people to really understand them, and that showing them on simplistic code doesn’t work well. Someone said that his company runs coding dojos to refactor real production code with the idea to throw the result away, so people are free to experiment and play with the design.

Related post: Effective exercises for teaching TDD.