Useful infrastructure testing abstractions over the popular Terratest library
Перейти к файлу
Mathieu Ouellet 1ea889ddd8
Skip "Terraform Plan Is Not Empty" validation when ExpectedResourceCount is at zero (#12)
* Skip plan not empty check when resource count is at zero

Signed-off-by: Mathieu Ouellet <mathieu.ouellet@energumen.io>

* Add plan validation helpers

Signed-off-by: Mathieu Ouellet <mathieu.ouellet@energumen.io>
2022-01-28 10:49:05 -05:00
.github Don't fail if testing workspace matches workspace in environment (#10) 2021-02-26 14:10:09 -07:00
integration Allow skipping terraform init on already initialized working directory (#5) 2021-01-11 09:02:25 -07:00
samples Add terraform command output validations (#7) 2021-03-01 08:43:31 -07:00
unit Skip "Terraform Plan Is Not Empty" validation when ExpectedResourceCount is at zero (#12) 2022-01-28 10:49:05 -05:00
.gitignore Don't fail if testing workspace matches workspace in environment (#10) 2021-02-26 14:10:09 -07:00
CODE_OF_CONDUCT.md Initial CODE_OF_CONDUCT.md commit 2020-04-14 11:47:52 -07:00
LICENSE Initial LICENSE commit 2020-04-14 11:47:53 -07:00
README.md fix module name (#2) 2020-04-17 14:23:12 -05:00
SECURITY.md Initial SECURITY.md commit 2020-04-14 11:47:56 -07:00
go.mod Skip "Terraform Plan Is Not Empty" validation when ExpectedResourceCount is at zero (#12) 2022-01-28 10:49:05 -05:00
go.sum Skip "Terraform Plan Is Not Empty" validation when ExpectedResourceCount is at zero (#12) 2022-01-28 10:49:05 -05:00

README.md

Terratest Abstraction

This Go package offers abstractions over the popular Terratest library in order to abstract some common testing patterns that have been identified through multiple projects that deploy Infrastructure as Code (IAC) using Terraform. The abstractions offered here can be used along side existing Terratest code and are quite easy to drop into existing projects. Feedback and OSS contributions are welcome!

When to use?

Development teams that rely on automated deployments of any kind demand robust automated validation of those environments in order to have confidence in changes. The results of these automated changes will allow software and operations engineers to sleep well at night, knowing that large classes of defects will be caught by repeatable and automated checks against their runtime systems. These concepts apply equally to software and infrastructure deployments.

terratest-abstraction offers an intuitive interface to testing Terraform deployments that offers a more declarative approach to writing test cases. There is support for testing the Terraform Plan as a pre-deployment unit test and Terraform Output as a post-deployment integration test.

Getting started

Writing unit tests

A full example unit test is included in the samples directory. Check out unit_test.go to see a unit test for the included sample main.tf. The included README.md provides instructions for running this example.

Writing integration tests

A full example integration test is included in the samples directory. Check out integration_test.go to see a unit test for the included sample main.tf. The included README.md provides instructions for running this example.

Automating in CICD pipelines

Tests written with terratest-abstraction can be invoked like any other Golang test. We recommend separating unit and integration tests so that they can be easily targeted at build and deploy time within an automated CICD pipeline. The samples all follow this structure:

$ tree
├── README.md
├── main.tf             # other terraform files live here
└── tests
    ├── commons.go      # common test code lives here
    ├── integration     # integration tests live here
    └── unit            # unit tests live here

If you follow this structure, then it is easy to invoke tests written with terratest-abstraction using the following commands:

Unit Tests

# before executing `terraform plan`
go test -v $(go list ./... | grep unit)

Integration Tests

# after executing `terraform apply`
go test -v $(go list ./... | grep integration)

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.