Experimenting with TDD Ping Pong

One of the items that came out of our team sprint retrospective a few weeks ago was Test Driven Development (TDD).
I’ve personally been following TDD for around a year, so the concept of test-first was nothing new to me. Having said that, on more than one occasion during this period I’ve found myself under a tight deadline and have fallen into the trap of writing code without tests first. Every single time I’ve done this, I’ve lived to regret it.
I joined my current team about a month ago, and the codebase we’re working on doesn’t actually have 100% test coverage. By no means do we work in a non-test culture, but there’s some legacy code that’s fairly difficult to test, so sometimes the test first concept is tough to run with even though the will is there. On top of the unit test suite, there are extensive integration and acceptance test suites.
Pair programming has been heartily embraced by the whole scrum team. Maybe that’s because it’s a new team, formed only a few weeks before I joined, and is made up of a real mixture of people in terms of both experience and codebase.
We decided that rather than all of us separately jumping straight into TDD, we would give TDD Ping Pong a try. For those not familiar with the concept, it’s fairly straight forward. You pair-programme, handing the keyboard back and forth after writing a test or getting a test to pass.
The standard pattern is…

• Programmer A writes and runs the simplest test they can think of that will fail
• Programmer B writes the code to get the test to pass
• Programmer A writes and runs the simplest test they can think of that will fail
• Programmer B writes the code to get the test to pass

But to keep things fresh, we tried something a bit different…

• Programmer A writes and runs the simplest test they can think of that will fail
• Programmer B writes the code to get the test to pass
• Programmer B writes and runs the simplest test they can think of that will fail
• Programmer A writes the code to get the test to pass

This process is repeated until all of the functionality is in place and a beautiful set of tests has spawned simply from writing the code.
The advantages we noticed were that…

• … when new to TDD, you’re reminded to write the tests first
• … a well-formed set of tests are created during the process
• … the resulting code is clean and well thought out

Of course, TDD is not the quickest of methods when you first start out, and it can be tough to get used to. It’s very easy to fall back into your old routine of writing code worrying about testing later. For teams that are new to TDD, Ping Pong is a great way to collaborate, share ideas and ingrain the TDD process. It really forces you to write the tests first, and I saw the benefits of having two heads during the initial coding stages.
I would highly recommend the Ping Pong technique to those new to TDD, and to those in teams where not every member is writing test driven code yet, though there’s a desire to move towards doing so.
For my part, I’ll continue to write test driven code as much as possible and hope that we can bring TDD Ping Pong into future sprints and widen the use of TDD throughout the scrum team’s development.
Comments or questions? Tweet us at @maydendev