Applying sound coding practices when testing infrastructure

Just as a big benefit of TDD, is that your component design improves; writing tests while designing and building systems - rather than afterwards - forces you to improve your designs. A component that is difficult to test in isolation, is a symptom of design issues. 

These are my reflections, lessons learned and brief summary of chapter 9 of Infrastructure as Code and is part of the Infrastructure as Code series.

Design your components to be small and focused, e.g. installing an application runtime (.NET, JRE, ...) onto a server and then ensuring that it (dotnet, java) is available on the path.

When it comes to testing, consider taking steps to syntax check and lint your infrastructure code, before you ask your cloud provider to provision resources for you. This will save you time and, money and headaches:

When you finally want to provision your infrastructure, you'll want your infrastructure isolated from other unrelated infrastructure. Therefore, aim for an ephemeral environment that is provisioned from scratch and then removed after testing is completed. Once that is built, look for way to optimize it by having parts of it built outside of the build cycle (e.g. the teardown - you don't need to wait for that to validate your test; have a separate process deal with it). If you have properly componentized your infrastructure, you should soon be able to stand on your own shoulders by having pieces of infrastructure depend on other pieces of successfully provisioned and deployed pieces, thereby speeding your testing up even further.

Implement your test orchestration in a separate script or tool from your CI pipeline and have your CI pipeline pass in a minimum of configuration parameters to keep your orchestration loosely coupled.



Comments

Popular posts from this blog

Auto Mapper and Record Types - will they blend?

Unit testing your Azure functions - part 2: Queues and Blobs

Testing WCF services with user credentials and binary endpoints