Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Best practices for test-driven development

Simplify your application of TDD

  • Print
  • Feedback

Page 5 of 5

We also attempted to do pairing without using test-first development. We tried test-last development while pairing. For us, that meant implementing a fair chunk of functionality prior to writing any unit tests, then retroactively creating the necessary tests. We sometimes went a long time without writing unit tests. We found many limitations to this approach. The person sitting in the backseat frequently became bored, and the person driving did all of the development and thinking about the next piece of functionality to implement. The two developers rarely verbally communicated. We found it too easy to lose track of our objective, plus there was a much greater chance we'd need a debugger to track down problems in our code.

Test-first development, in contrast, gives us clear next objectives: identify the next test we want to write, create the mock objects we need, and implement the necessary production code to make the test pass. The back-seat driver typically thinks about the next test to write and the necessary mock objects, while the person driving focuses on getting the current test to pass. The developers communicate more, as the back-seat driver keeps the front-seat driver focused on the current task, which is well understood between both developers.

We found pairing to be productive when employing test-first development. We were pleased with our code quality and unit-test coverage, and felt our time was well spent. In contrast, when pairing without doing test-first development, we were less pleased with the resulting code and unit tests, and felt much of the person's time in the backseat was poorly spent. We found that if pairing and test-first development are not used together, the perception of pairing as "two coders doing the job of one" may be true—effectively reducing productivity by half. But if the two practices are used together, each person's role and usefulness is fully maximized. For us, TDD and pairing complemented as well as justified each other.

We hope these best practices for employing TDD help you use TDD efficiently in your next development project.

About the author

Michael Grove and Brooks Bollich are software engineers for HP. Grove graduated with a BS in computer science from Carnegie Mellon University in 2000, and Bollich has a BS in computer science from the University of New Mexico. Both have worked extensively in software engineering best practices, including the study of design patterns, refactoring, pairing, and test-driven development.

Read more about Tools & Methods in JavaWorld's Tools & Methods section.

  • Print
  • Feedback

Resources