In our last post, we shared how the State Farm engineering community is beginning to help others in the form of open-source projects. Today, we’re going to continue that series looking at our second open source project, Terratest Helpers. At State Farm, IaC (Infrastructure as Code) is absolutely critical to how we build applications. It provides our teams with control and consistency for the infrastructure our products run on.
Terraform is a highly adopted IaC language and every language needs a testing framework. Terratest is that framework, but the benefit of the terratest-helpers is that when you deploy resources to AWS/GCP/Azure they are built based on the inputs you pass to the terraform. This allows the terratest-helpers to take in the same inputs and validate that the resources are built correctly in the cloud provider by making API calls to validate. The reason this is possible is because when people deploy resources to a cloud provider they specify the configuration they want. It is not custom code like a JUnit is. This allows the developers to not focus on writing all of the API calls to verify the resources built correctly in the cloud provider. They just specify what resource they are building and the terratest-helper function will do all of the validation for them.
Include this in your .go terratest file:
import ( "github.com/StateFarmIns/terratest-helpers/tests" ) // ... code tests.ValidateBucketEncryption(t, svc, "my-bucket-name", "AES256", verboseOutput)
The idea initially came to me when I first started on our cloud enablement team a couple years ago. I was assigned the task to create our automated testing strategy for Terraform not only for my team, but for the whole SF cloud community. I researched a lot of testing frameworks for Infrastructure as Code (IaC) and determined that Terratest best suited our needs.
As I started writing test cases for all of our AWS resources that are deployed with Terraform like IAM roles, S3 buckets, VPCs, etc. I noticed a common pattern when it came to asserting that what you wrote in code actually matches what gets deployed into the cloud. This is when I got the idea to break out all of the assert statements that I kept having to repeat for each AWS resources and that is how terratest-helpers were born.
Now that the strategy for testing your Terraform code had been determined, we started to publish and advocate for Terratest. As adoption for the testing framework grew, so did the reusability for terratest-helpers. The feedback was positive, and we were even asked to add more tests and if other engineers could help contribute. The adoption within State Farm was growing and I realized that there is nothing State Farm specific in terratest-helpers so why not make it open source for everyone to use!
Check out terratest-helpers and start writing some reuables test cases yourself!