When Infrastructure-as-Code (IaC) took off and became popular, it was thought of way differently than application code. The reason why is because different types of engineers were using IaC. Systems administrators, IT technicians, and infrastructure engineers used it way more in the beginning. Today, you see everyone using IaC - infrastructure pros, developers, etc.

Now that it's being used by developers, the understanding and importance of testing is becoming known. Why? Because developers are used to testing code, and at the end of the day, code is code. All code should be tested, regardless of it's use-case.

In this blog post, you'll learn about why you should be testing IaC, the best platforms to get started with, and an introduction to one of the most popular IaC tools out there today.

Why Test?

Understanding the outcome of any piece of code is crucial for engineers and businesses. Think about it like milk. If you go to the store and buy some milk, you expect to see an expiration date. That expiration date helps you understand the outcome of buying the milk (how long you have to drink it, how long it'll stay good for, etc.).

With code, knowing if it works the way you're expecting it to or if it'll "expire" at some point (libraries no longer used, functions called upon change, bugs due to taking out old dependencies, etc.) is the difference between running successful builds 99% of the time or failed builds/deployments 99% of the time and not understanding why. Writing tests allows you to (hopefully) know what negative impacts can happen before they occur, if the code is working the way you're expecting, and if the proper resources are being created. The same is true for application code, infrastructure code, automation code, or scripts.

You may be thinking to yourself I wrote the code, ran it locally, and tested it, so I know it works. That's true, but ask yourself this question - let's say you commit that code to source control (which you should), someone on your team pulls down the repo, makes a change, and pushes the code back to source control. How do you know that the code still works? Another question you can ask yourself is; if you're using libraries, modules, and dependencies in your code, that means you're using someone else's code inside of yours for different types of functionality. How do you know that library/module/dependency will always perform the way you're expecting?

Testing Platforms

• checkov — https://github.com/bridgecrewio/checkov/
• tflint — https://github.com/terraform-linters/
• terratest — Terratest | Automated tests for your infrastructure code. (gruntwork.io)
• terrascan — https://github.com/cesar-rodriguez/terrascan (no TF 0.13 support at this time)
• Built-in Integration testing in Terraform

Checkov, created by Bridgecrew, is a way to implement Policy-as-Code for Terraform. It's among the most popular IaC testing tools. Terratest, which allows you to write unit/mock/integration tests via Go (golang), was created by Gruntwork, which is a DevOps-as-a-Service organization. One of the co-founders also wrote a book called Terraform Up & Running, which is very popular in the community. Tflint is a popular open-source tool to test Terraform code from a linting perspective. Terrascan, created by Accurics, is a static code analyzer (like SonarQube) for Terraform code. Finally, there's the built-in integration testing via Terraform. This is still fairly new at the time of writing and is still in beta.

Getting Started With Checkov

In this section, you'll learn how to get started with Checkov to start implementing Policy-as-Code for Terraform code.

To get started, you'll need:

• Terraform code. If you don't have any, you can clone and use this repo.
• pip installed, which is Pythons package manager.

The first thing you'll need to do is install Checkov with pip by running the command below:

pip3 install checkov

Next, change directory (cd) to where you stored the Terraform code. You must ensure to be in the same directory where your Terraform resources are, like your [main.tf](http://main.tf) file.

Once you're in the proper directory, you can run the test by using the following command:

checkov -d .

You'll see an output similar to the screenshot below showing what tests passed, failed, and remediation techniques.