Agile 2006: The Test-Driven Development Pairing Game – Peter Provost, Mitch Lacey, Brad Wilson

Thursday 15:30 – 17:00

Abstract

A new twist on pair programming that combines test driven development, or test driven design, with pair programming to create a game.

Summary

This was the only session of the entire conference that I had decided in advance there was no way I was going to miss. I’d heard about the technique and was really interested to find out more so that I could take it home. I wasn’t disappointed – Peter and Brad have so much energy and passion, and their constant banter made the session really entertaining.

It was a live demonstration, and the application they chose to demonstrate it (building a simple bank account object with unit tests) worked really well – I intend to use the same idea to demonstrate back to my team.

There are three legs to the development “stool”:

  • Test driven design
  • Real time code review
  • Refactoring

Developers want to get the most out of their time, and traditional pair programming can be boring for the navigator. The driver is the tactician and the observer should be the strategist, but in practice they are often thinking about email, lunch, or what they’re going to do next.

TDD evolves the design of the system. In TDD, a test is written before writing the code, then just enough code is written to pass the test, then the design is improved: write – run – refactor.

Refactoring improves the design without changing the functionality. If more tests are necessary, then it’s not refactoring.

In the TDD Pairing Game, the keyboard is passed at every step, which means it goes back and forth very rapidly – each step should not take more than 3-4 minutes. The pair negotiate over disagreements, so it ends up being a process of negotiation. The test writing drives the design.

  • Step 1 – write a test that compiles, but doesn’t pass. Pass the keyboard.
  • Step 2 – write enough code to make the test go green. Pass the keyboard
  • Step 3 – either write another test, or go back and do one refactoring.

The rules of the game are simple:

  • If the test light is red, the next step must be to make it go green.
  • If the test light is green, choose whether to write a successful test, a failing test, do a refactoring, or stop and think strategically about the system design – use the whiteboard to diagram it, etc.
  • If the system doesn’t compile, the keyboard can’t be passed.
  • Don’t write too much code. Throw exceptions if things are not yet implemented. You’ll be surprised where it leads you if you don’t write too much code.
  • One test at a time to evolve the game.
  • No email, no phones with email, no IM.
  • It’s recommended that developers should check in as much as possible – at every green light, if it’s cheap enough. Source control is a big giant undo button.

Tests have three separate code “paragraphs”: arrange, act, assert. Set up and teardown are considered evil – factory methods can be used instead. Whether we unit test edge cases or not, is a design question.

Ideas for new tests are kept in comments in a list, which evolves as you start coding. If a test gets too big, comment it out, then go back and refactor.

Recommended further reading

Avoid Setup and Teardown – http://www.agileprogrammer.com/oneagilecoder/archive/2005/07/23/6261.aspx

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>