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,
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)
- 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)