I’ve now been to Keith Braithwaite’s TDD as if you meant it session twice and also ran a series of coding katas in this style at work using Conway’s Game of Life.

Here’s the concept:

1) write exactly ONE failing test
2) make the test from (1) pass by first writing implementation code IN THE TEST
3) create a new implementation method/function by:
3.1) doing extract method on implementation code created as per (2), or
3.2) moving implementation code as per (2) into an existing implementation method
4) only ever create new methods IN THE TEST CLASS
5) only ever create implementation classes to provide a destination for extracting a method created as per (4).
6) populate implementation classes by doing move method from a test class into them
7) refactor as required
8 ) go to (1)

What I’ve learnt

• It’s really hard to get going.
• At first it feels ridiculous and pointless effectively testing things like true == false and having the code under test actually in the fixture.
• A recurring theme has been throwing away lots of code. Focusing on trying to do the simplest possible thing often means your understanding and your solution frequently changes and continuously becomes redundant. It’s a very frustrating experience.
• I don’t think it’s at all a practical way to write production code.

If I’m not going to use it what’s the point?

As Keith has repeatedly stated, he would not recommend you went back to your job and started coding this way. What it is though is an excellent training exercise, the equivalent of a musician practicing scales. It emphasises the core principles of TDD more than anything else I’ve tried or read.

Therefore I’d highly recommend it as something to do on a relatively regular basis to help refresh your TDD muscle memory and it’s a great way to introduce the concepts of TDD to the uninitiated.

As Queen Elizabeth II once said, “It’s all to do with the training: you can do a lot if you’re properly trained.”