Talk by Rowan Merewood, given on Tuesday the 29th of February

What is TDD ?

Rowan reminded us with what TDD is about :

• decide what you want to do,
• write the test,
• run it and watch it fail,
• write minimum piece of code,
• re run the test to watch it pass,
• refactor,
• repeat

Why is it hard ?

do you even know what you / your customer want(s) ?
Rowan took the analogy of a computer scientist with a ninja, repeating kata to master the perfect move:  http://codekata.pragprog.com , TDD Kata
Rowan went on with a demo of the design using TDD of a php class (with phpunit checking in the background for modifications to re run the test)

• First test : check the instantiation returns the good type ; it fails because the class is not existing, Rowan created the class (no methods no variables) re run, the test passed
• Second test : expects that a method called calc returns 0 :  it fails since the method add does not exist in the class under test, then Rowan wrote an add method that returns 0, and the test passed
• Third test same thing with add 1 : to make it pass, he just returned the param given to the method
• Fourth test : add (1,2) should return 3 : he parses the params into an array and array_sums it

So now, we’re ready to apply this at work

you should not try to implement all the tests at once : they won’t be maintanable / understandable and you will miss the deadline
You can try to « force tests » to your client : add a fixed percentage to your estimates, and do not compromise your principles
You can also try to « sell the tests » to your client : use tests to define done, involve the client in creating tests (automated hopefully) you can use fitnesse  selenium , behat  (can be seen as using cucumber to describe fitnesse tests), and make the tests a deliverable (use CI )
Do not over promise.

The steps to get you started with TDD :

• Unit testing and acceptance testing
• puppet/chef to enable continuous deployment re creating a fresh environment
• continuous integration to make progress visible
• issue tracking (it allows reporting on TDD)

Reporting :

• Code/branch coverage
• Bug origin (tested or untested code )
• For a begineer in TDD, a good idea can be to measure the amount of time spent testing vs amount of time spent coding

On a human side : owners vs heroes (a owner can spread the knowledge, a hero just fixes the problems during ight and keeps the knowledge to himself) and ff the team does not care : try games to imply them or… quit (!)
You have to accept not testing the legacy code; but you can wrap the calls to this legacy code and run tests against this wrapping api.

Running late ? drop features or test the happy path / test only the core(reduce the scope)
Broken build ? fix the test or disable/delete the test (some -legacy-tests can be wrong and their impact may be even worse than not having tests at all)