Automated Smoke Test Orchestration in Ephemeral Infrastructure with Terraform and Terratest

The Challenge of Validating Environments That Born and Die

In modern software engineering, provisioning servers manually has become a relic of the past. Today we use infrastructure as code, or IaC, which means writing text files to describe servers, networks, and databases. Through this approach, we create the concept of ephemeral infrastructure: entire environments that spring up on demand for a specific purpose, such as running automated tests, and then disappear without leaving a trace.

In practice, this prevents a test from failing due to leftover garbage from a previous execution. However, a new challenge arises: how to ensure that the newly created environment actually works before releasing production traffic? This is where smoke tests come in, a concept originally employed in electronics to check if a circuit smoked when first powered on, indicating a severe short-circuit.

In software development, a smoke test is a quick and superficial verification of a system's most critical features. When applied to ephemeral infrastructure, they check if servers responded, if databases accept connections, and if network routes are active. Without this automation, teams waste hours investigating failures that could be prevented with programmatic validations right at the first startup.

Choosing the Tools: Terraform and Terratest

To put this strategy into practice, we chose two established tools in the corporate ecosystem: Terraform and Terratest. Terraform, created by HashiCorp, is the leading tool for managing cloud resources declaratively, allowing you to build and destroy entire architectures with simple terminal commands. It reads our configuration files and talks to providers like AWS, Google Cloud, or Azure.

On the other hand, Terratest is a Go-written library developed by Gruntwork, specialized in testing infrastructure code. While Terraform only creates resources, Terratest can run verification commands immediately afterward. In practice, it acts like a rigorous building inspector who enters the newly constructed property to test if doors open and water runs through the taps before handing keys to the resident.

Using these tools together forms a virtuous cycle of safety and speed. The continuous integration pipeline triggers the creation of the temporary environment via Terraform, Terratest validates that everything is in place and responding, and right after that, the pipeline itself destroys the environment to save costs. If any step fails, the process is halted immediately, preventing incorrect changes from advancing to shared environments.

Writing Provisioning and Validation Code

To understand the workflow in practice, we need to structure our project by dividing it between infrastructure files and test scripts. We start by creating a basic Terraform module that spins up an isolated cloud server instance with a simple web application installed. This file defines the machine type, network security rules, and the startup script that initializes the service.

Next, we write the test code using the Go language and the Terratest library. The test must follow a rigorous logical execution sequence to ensure the environment is fully ready before performing HTTP validation requests. Below is a functional example of how this structure behaves in the project's test directory.

package test

import (
	"testing"
	"time"
	"github.com/gruntwork-io/terratest/modules/terraform"
	"github.com/gruntwork-io/terratest/modules/http-helper"
)

func TestTerraformAwsWebExample(t *testing.T) {
	terraformOptions := &terraform.Options{
		TerraformDir: "../examples/terraform-basic",
	}

	defer terraform.Destroy(t, terraformOptions)

	terraform.InitAndApply(t, terraformOptions)

	publicIp := terraform.Output(t, terraformOptions, "public_ip")
	url := "http://" + publicIp + ":80"

	http-helper.HttpGetWithRetry(t, url, nil, 200, "Hello, World!", 30, 5*time.Second)
}

In this code snippet, the test function initializes Terraform, applies the configuration to spin up the server, captures the generated public IP address, and uses an HTTP helper to attempt to access the web page repeatedly until it gets a two hundred status code. The command to destroy resources is guaranteed at the end of execution through a deferred command, which ensures that no server keeps running and generating undue costs.

Integrating the Lifecycle into the CI/CD Pipeline

Writing test code locally is only the first step; the true value of this approach appears when we insert the process into a continuous integration pipeline, such as GitHub Actions or GitLab CI. The automation server needs the necessary tools installed, such as the Go language interpreter, the Terraform CLI, and valid cloud access credentials.

During each code push to the repository, the pipeline executes the automated test command. In practice, this means any change to network configurations, security policies, or operating system versions will pass through Terratest's scrutiny before being accepted into the main branch. This eliminates the human factor of forgetting to test a critical infrastructure modification.

Beyond security, this practice transforms project documentation. Since the test code describes exactly the expected behavior of the infrastructure, new engineers can quickly understand which ports must be open and what HTTP responses the application needs to return. The code becomes the single source of truth, uniting development, operations, and quality assurance in a unified workflow.

Final Considerations on Operational Resilience

The adoption of ephemeral infrastructure combined with automated tests via Terraform and Terratest represents a profound shift in the operational maturity of technology teams. By treating infrastructure with the same code rigor applied to traditional software development, we eliminate the famous excuse that the system only worked on the developer's machine.

Although there is an initial learning curve to master the Go language and test syntax, the return on investment quickly pays off with a drastic reduction in production incidents. Systems that are born tested and die shortly thereafter ensure a much safer, more predictable, and scalable continuous delivery cycle for companies of any size.