Gruntwork open sourced their Go framework Terratest which can be used to write automated tests for testing infrastructure. The library comes with support for Terraform and Packer.
Gruntwork open sourced their Go framework Terratest which can be used to write automated tests for testing infrastructure. The library comes with support for Terraform and Packer.
Terratest was developed internally at Gruntwork to maintain their Infrastructure as Code (IAC) library, a repository of tools based on Terraform, Python, Go and bash for managing infrastructure on AWS. IAC is available to paying Gruntwork users.
Writing tests in Terratest involves using Go’s inbuilt package testing mechanism. A test run creates real infrastructure components like servers, deploys applications on them and validates the expected behaviour using Terratest tools. At the end of the test, Terratest can undeploy the apps and cleanup resources using Go’s defer mechanism, similar to JUnit’s teardown method. Can Terratest run against an existing infrastructure deployment instead of creating it from scratch each time? The tool wiki recommends against this as it might create undesirable changes in the environment. However, this can be difficult to follow for some teams who have complex infrastructure topologies and do not wish to create an entirely new setup to run the tests. A feature called namespacing can isolate resources by using unique identifiers. Note that namespacing here does not translate to the generally understood term of isolating components by tagging them with labels, but rather to ensuring unique identifiers for resources and using only those resources for testing which have the identifiers generated in the test framework.
Yevgeniy Brikman, co-founder of Gruntwork, explains the reasons behind choosing Go for writing Terratest:
Go is becoming the lingua franca of the DevOps world, so it seems like a reasonable choice. Python is the only other language we would’ve considered for this sort of library in the DevOps space, but we use Go extensively elsewhere at Gruntwork, so it made sense to stick with it.
In response to how Terratest compares to other tools like InSpec and ServerSpec, Brikman said
Most of the spec tools focus on checking the properties of a single server or resource. For example, is httpd installed and running? Terratest is largely for end-to-end, acceptance style testing, where you deploy your real infrastructure, in a real environment (e.g., AWS), and test that the infrastructure actually works as expected.
Terratest comes with tools that can perform tasks like checking a URL for an expected response, or fetching the name of the current branch in Git. The Terraform modules for Consul, Vault and Nomad have Terratest examples for testing the same. Terratest’s other features include workarounds for CI systems that expect short running tests – which might not be valid for infrastructure tests that can run for long periods – as well as typical testing abstractions like testing expected errors. To speed up dev-time testing, Terratest can break tests down into « stages » where stages can be skipped by using environment variables.
