Confoo 2012 : TDD and getting paid

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

Une réflexion sur « Confoo 2012 : TDD and getting paid »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.

Le temps imparti est dépassé. Merci de saisir de nouveau le CAPTCHA.

Ce site utilise Akismet pour réduire les indésirables. Apprenez comment vos données de commentaires sont traitées.