Infrastructure as Code

Chapter 11. Testing Infrastructure Changes

The previous chapter described how software engineering practices such as CI and CD can be applied with infrastructure as code. A major theme of that chapter was managing quality. This chapter drills into specifics of testing, especially automated tests. Automated testing is essential to be able to continuously test changes to a system. But many teams find building and maintaining an automated test suite difficult to sustain. This chapter looks at approaches used by teams who do manage to establish and keep up automated testing regimes.

The purpose of testing is to help get work done quickly. Sadly, in many organizations testing is seen as something that slows work down. There is a common misconception that quality and delivery speed are opposing forces that must be traded off, one against the other. This mindset leads to the idea that automation can speed the delivery process by making the act of testing a system go faster.

These misconceptions—testing as the enemy of delivery speed, and automation as a silver bullet to make testing go faster—lead to expensive, failed test automation initiatives.

The reality is that system quality is an enabler of delivery speed. Investing less time to find and fix problems results in a fragile system. Fragile systems are difficult to change, so changes are time consuming and risky.

The goal of automated testing is to help a team keep the quality of their system high by identifying errors as soon as ...