Terratest v1.0.1 - V1 Maintenance And Deprecation Notes


Terratest v1.0.1 was published on June 27, 2026, and it marks the start of the Terratest v1 maintenance phase. The important part for platform teams is the deprecation map: several helper packages now point readers toward Go standard library calls or direct client use, while runtime behavior stays unchanged. This is a stable release, not a prerelease.

The full release notes and downloads are on the GitHub release page.

The release notes define the v1 policy in concrete terms. Security fixes continue on the v1 branch until 12 months after v2.0.0 reaches general availability. The notes also say this commit becomes the permanent v1 head, with a long lived v1 branch cut from it.

That matters for IaC test suites because Terratest often sits in validation jobs around Terraform, Terragrunt, Helm, Packer, and Kubernetes. A runtime neutral maintenance branch lets teams pin v1 while planning imports for new /v2 module paths. The import path map lives at docs/v2-import-map.md, which gives migration work a fixed document instead of scattered release note archaeology.

Five packages get // Deprecated: annotations: modules/collections, modules/environment, modules/git, modules/version-checker, and modules/slack. The release notes say each symbol includes concrete guidance. That changes the upgrade work from a search project into a set of targeted replacements.

For data platform code, the practical reading is simple. Use slices where collection helpers were hiding plain Go behavior. Read environment variables with os.Getenv at the call site. Shell out through os/exec when a test must inspect Git or a binary version. For Slack notifications, call github.com/slack-go/slack directly instead of wrapping it through Terratest.

The release does not remove these packages. It creates the warning surface that teams need before v2 import work begins.

Several changes are small but operator visible. Helm tests can use install --generate-name by omitting an empty release name, which matches the CLI behavior people already use in charts with generated names. Kubernetes checks now surface container status inside PodNotAvailable errors, so a failed wait has a better chance of showing the actual container state instead of only a pod level symptom.

Packer support also tightens. Directory templates now get packer init, which is the path modern Packer modules expect before validation or build steps. AWS coverage adds ECR Public repository support, useful when test code has to assert public image repository shape instead of only private ECR state.

These are not broad API rewrites. They are sharper edges on common validation workflows where the error message or setup step is often the difference between a quick fix and another rerun.

Terratest v1.0.1 bumps Kubernetes dependencies to v0.36.2 and moves the Terragrunt pin to 1.0.5. It also updates github.com/slack-go/slack from 0.15.0 to 0.23.1. Those changes matter less as feature news and more as alignment work for test runners that compile Terratest alongside Kubernetes clients, Terragrunt fixtures, and notification code.

The CI changes are mostly maintenance. Tag pushes now build and publish release binaries. The lint configuration was refreshed, stale issue automation was added, and a Terragrunt specific go-getter depguard rule was dropped. The docs also add a scope page for what Terratest is for, plus the v1 maintenance note and import map.

This section of the release is mostly internal cleanup. It still matters to operators because release packaging and dependency pins decide how much local patching a platform test image needs.

This release is designed as a no behavior change upgrade for recent v1 consumers. The work to schedule is not forced by v1.0.1; it is the future v2 migration. Start by scanning for imports of modules/collections, modules/environment, modules/git, modules/version-checker, and modules/slack, then compare them with docs/v2-import-map.md.

Teams that vendor Terratest into long lived CI images should treat the GitHub release page as the release source and keep the v1 branch policy in their dependency notes. Security fixes continue on v1 until 12 months after v2.0.0 general availability.