Test-Driven Infrastructure with Chef, 2nd Edition

Chapter 5. An Introduction to Test- and Behavior-Driven Development

The Principles of TDD and BDD

In Chapter 1, I argued that, to mitigate against the risks of adopting the infrastructure as code paradigm, systems should be in place to ensure that our code produces the environment needed, and to ensure that our changes have not caused side effects that alter other aspects of the infrastructure.

What we’re describing here is automated testing. In his book Managing Software Debt: Building for Inevitable Change (Addison-Wesley), Chris Sterling uses the phrase “a supportable structure for imminent change” to describe what I am calling for. Particularly as infrastructure developers, we have to expect our systems to be in a state of flux. We may need to add components to our systems, refine the architecture, tweak the configuration, or resolve issues with its current implementation. When making these changes using Chef, we’re effectively doing exactly what a traditional software developer does in response to a bug or feature request. As complexity and size grow, it becomes increasingly important to have safe ways to support change. The approach I’m recommending has its roots firmly in the historic evolution of best practices in the software development world.

A Very Brief History of Agile Software Development

By the end of the 1990s, the software industry did not enjoy a particularly good reputation—across four critical areas, customers were feeling let down. Firstly, the perception (and ...