Test-Driven Development
Out of the Agile movement emerged a number of core practices which were felt to be important to guarantee not only quality software but also an enjoyable working experience for developers. Ron Jeffries summarises these excellently in his article introducing Extreme Programming,[11] one of a family of Agile approaches that emerged in the early 2000s. Some of these practices can be introduced as good habits, and don’t require much technology to support their implementation. Of this family, the practice most crucial for creating a supportable structure for imminent change, providing insurance and warning against unwanted side effects, is that of test-driven development (TDD). For infrastructure developers, the practice is both the most difficult to introduce and implement, and also the one which promises the biggest return on investment.
TDD is a widely-adopted way of working that facilitates the creation of highly reliable and maintainable code. The philosophy of TDD is encapsulated in the phrase Red, Green, Refactor. This is an iterative approach that follows these six steps:
Write a test based on requirements.
Run the test, and watch it fail.
Write the simplest code you can to make the test pass.
Run the test and watch it pass.
Improve the code as required to make it perform well, be readable and reusable, but without changing its behavior.
Repeat the cycle.
Kent Beck[12] suggests this way of working brings benefits in four clear areas:
It helps prevent scope from ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access