gruntwork-io/terratest

Terratest is a Go library that makes it easier to write automated tests for your infrastructure code.

View on GitHub ↗Jump to charts ↓

Summary Information

Updated 14 minutes ago
Added to GitGenius on September 8th, 2026
Created on March 5th, 2016
Open Issues & Pull Requests: 14 (+0)
GitHub issues: Enabled
Number of forks: 1,372
Total Stargazers: 7,943 (+0)
Total Subscribers: 107 (+0)

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Issue API getrepoissuespagesummary failed: 429 Rate limit exceeded. Please try again later.

Detailed Description

Terratest is a Go library that makes it easier to write automated tests for your infrastructure code.

Terratest addresses the challenge of testing infrastructure-as-code by providing a collection of helper functions and patterns for common testing scenarios. Rather than requiring developers to build testing utilities from scratch, the library offers pre-built abstractions for validating Terraform configurations, Packer templates, Docker images, and cloud infrastructure across AWS, Azure, and GCP. It also supports testing Kubernetes deployments and Helm charts, executing remote commands over SSH, and making HTTP requests, allowing tests to verify both the infrastructure definitions and their runtime behavior.

Teams should adopt Terratest when they need to validate infrastructure code as part of their development workflow and prefer writing tests in Go. The library suits projects already using Go for tooling or those where the testing team has Go expertise. It works well for organizations testing Terraform modules, container images, or multi-cloud deployments that span AWS, Azure, and GCP. The library's breadth of helper functions means less boilerplate code compared to writing raw Go tests against cloud provider SDKs.

The project maintains semantic versioning from v1.0.0 onward, with breaking changes reserved for major version releases. Deprecated symbols in v1 carry annotations pointing to replacements, with removals deferred to v2. The v1 line entered maintenance mode with v2 in development, receiving security fixes only for a defined period while v2 ships under separate module paths, allowing existing consumers to upgrade on their own schedule. Migration guides are provided for both the v1 transition and the path from v1 to v2.