We write tests to build confidence in our tools and infrastructure code(infracode). This is helpful when collaborating on code as this can help eliminate some of the fear of making a change to the systems. The goals of testing is to help you assess risk, respond to and recover from problems quickly, and improve your delivery processes.
In this chapter, I revisit linting, unit and integration testing in practice. You’ll get real examples, and learn a bit more about infrastructure and writing tests for infrastructure.
A challenge of writing unit tests for infracode is that it can be very easy to test the infrastructure platform in use rather than your code. Think about the test and whether it’s verifying the code as written, or testing that the infrastructure as code software is working. Unless it’s an in-house developed system, trust that the software does what it is supposed to do. Even if you are working with an in-house developed configuration system, test that platform in it’s git project separately from your infrastructure code project.
With infracode unit tests, there generally is a specific package that maps out to testing the platform you are using. For example, Chef has Chefspec, and puppet has rspec-puppet.
Let’s dig into infracode unit testing with Chef. Remember, the key is to focus on broad principles and concepts. While you may not use Chef in your environment, you can apply the testing concepts and ...