We have been working for some time on a book about our approach to developing software test-first. We've been working at it long enough that we though it was time to start putting up some material to get some feedback which, after all, is a technique we go on and on about. We'll start with chapters in HTML, then add some PDFs on the side as the material grows.
Here's our opening.
A Deceptively Simple Idea
Test-Driven Development (TDD) is a deceptively simple idea: write the tests for your code before writing the code itself. We say “deceptively simple” because this reversal fundamentally changes the role that testing plays in the development process and challenges the industry's assumptions about what testing is for. Testing is no longer just about keeping defects from the users, instead it's about helping the team to understand the features that the users need and to deliver those features reliably and predictably. When followed to its conclusions, TDD radically changes the way we develop software and, in our experience, dramatically improves the quality of the systems we build, in particular their reliability and their flexibility in response to new requirements.
Test-Driven Development is widely used in “agile” software development methods. It is a core practice of Extreme Programming (XP) [Beck99], is recommended by Crystal Clear [Cockburn04] and often used in Scrum™ [SB01] projects. If you're going to work on an agile project, you will probably use TDD. We've used TDD on every agile project we've been involved in and have snuck the practises in to non-agile projects. We've even found it useful in pure R&D projects that explore possibilities rather than meet customer needs and so have no need of the customer-facing project management practices of agile methods.
The Table of Contents links to the published chapters.
Feedback and Discussion
If you want to give us feedback on what we've written so far and see what other people think about it, please join the discussion group.