When Infrastructure-as-Code (IaC) took off and became popular, it was thought of way differently than application code. The reason is that 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 of testing is increasing. 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 its 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 that . 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? I wrote the code, ran it locally, and tested it, so I know it works Testing Platforms — checkov https://github.com/bridgecrewio/checkov/ — tflint https://github.com/terraform-linters/ — terratest Terratest | Automated tests for your infrastructure code. (gruntwork.io) — (no TF 0.13 support at this time) terrascan https://github.com/cesar-rodriguez/terrascan 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 repo. this installed, which is Pythons package manager. pip The first thing you'll need to do is install Checkov with pip by running the command below: pip3 install checkov Next, change directory ( ) to where you stored the Terraform code. You must ensure to be in the same directory where your Terraform resources are, like your file. cd [main.tf](http://main.tf) 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. Also published . here

Different

Is VSM the New Way to Measure DevOps?

AI-Driven DevOps: Everything you Need to Know

Nominated for 2022 - HackerNoon Contributor of the Year - Software Testing

How to Test Terraform the Right Way

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

AI-Driven DevOps: Everything you Need to Know

10 Trends That Every Tech Recruiter Needs to Know in 2022

Code Quality Guardians: The Power of Continuous Integration in Software Development

DevOps Pipeline: The Ultimate Cheat Sheet

How to Test Your Postgres Business Logic with Jest Plugin

Why I Switched to Table Driven Testing approach in Go

AI-Driven DevOps: Everything you Need to Know

10 Trends That Every Tech Recruiter Needs to Know in 2022

Code Quality Guardians: The Power of Continuous Integration in Software Development

DevOps Pipeline: The Ultimate Cheat Sheet

How to Test Your Postgres Business Logic with Jest Plugin

Why I Switched to Table Driven Testing approach in Go

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps