Test-Driven Infrastructure with Chef

Chapter 4. Behavior-Driven Development (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. Chris Sterling uses the phrase “a supportable structure for imminent change”^[10] 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 grows, 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 expectation, and experience) was often that software would be delivered late and over budget. Secondly, despite a lengthy cycle of requirement ...