Why We Advocate Test-Driven Development

Gerald Weinberg, an American computer scientist, once famously stated that “If builders built houses the way programmers built programs, [then] the first woodpecker to come along would destroy civilisation.” While this was far from a chirpy portrayal of the current state of software engineering, for many companies out there, it remains an accurate assessment today. The ongoing predicament facing developers, however, is not without reason.

The first issue is a matter of complexity. Modern software projects are highly intricate systems, and while competent programmers may well be able to single-handedly ensure quality of code, the process of implementing every piece of functionality can take them years. Unfortunately, however, no customer is ever willing to wait that long. As a result, software development has largely become a team effort, but this poses its own set of challenges.

Because customers expect projects to evolve in tandem with their organisations, success relies heavily on the team’s ability to be flexible, as they must be willing to continuously adapt their code in the face of rapidly changing requirements. Yet the main difficulty remains — every touch to the project codebase can cause unpredictable damage to the system. This is why it is so important to test software with every code alteration.

But this is not standard practice. Failing to see immediate benefits, most companies prefer to only test their software with every release. By contrast, Software Planet Group take the approach of Kent Back, the creator of the Extreme Programming (XP) methodology. Beck’s far-sighted answer to these problems was a unique style of software engineering he called Test-Driven Development (TDD).

Conceived in 1999 as a practice within the greater XP method, TDD is often thought to be a bit too extreme for companies to adopt, but this is mainly a result of misunderstanding the process. Beck’s brainchild is also called “test-first approach” because it instructs developers to first write the code that will validate their work and then subsequently the piece of functionality that will enable that validation to pass. While this may all sound inordinately confusing, the process can be compared to pinning a target before shooting. In this way, whenever developers define goals for a project, often without realising it, they also improve the general software architecture and quality of code.

The mantra of Test-Driven Development is “red, green, refactor.” In practice, software engineers begin by writing a unit test that succinctly defines a function of the system. Because there is no code to allow the test to pass, we call this the red phase. After this initial step, developers go on to write the minimum amount of code that is necessary for the test to pass, and when this is done successfully, the green phase is reached. Finally, the code is restructured or “refactored” into a more elegant module, after which the cycle is repeated for every required feature.

Because TDD serves as a very simple way to document the intended functionality of one’s code, programmers who later join the team are uniquely equipped to gain a speedy understanding of the project. This makes it faster, safer and easier to modify code as development advances. The rapid succession of small cycles used in TDD also make it an ideal match for pair programming, as software engineers are able to work through design problems together, generating exceptionally well-structured code.

All in all, the main benefit of TDD is it forces developers to carry out critical tasks that are currently neglected by a majority of software companies. This means programmers are led to make architectural decisions, write unit tests for the total functionality of the project and focus on important features rather than the technical details of implementation. With this bird’s eye view of development, it takes a lot more than a woodpecker to bring a project down.

By correctly employing Test-Driven Development, Software Planet Group are able to give projects a firm foundation in their infancy while guaranteeing flexibility and efficiency as they mature. Our first-hand experience of the benefits of TDD have made us avid proponents of its use in all our projects.

David Blackwood

Post A Reply