Your Infrastructure Passed CI. But Was It Tested Properly?

What Terraform and OpenTofu can verify, and where infrastructure testing still needs additional checks.

Consider a team preparing an infrastructure change for production. The Terraform configuration passes validation, the deployment plan looks correct, and the CI pipeline finishes without errors.

Later, a security review identifies an Amazon S3 bucket configuration that could permit public access, contrary to the company’s policy. This is an illustrative example, not a report of an actual incident.

Terraform may have done exactly what was asked of it. The configuration is valid, and the plan shows the proposed changes. What the pipeline did not establish was whether those changes met the company’s security requirements.

Terraform and OpenTofu already support tests that help teams detect problems in infrastructure modules before deployment. OpenTofu 1.13, released in September 2026, also introduced experimental built-in linting. These capabilities invite a practical look at which checks belong in the IaC workflow and which ones need separate enforcement.

Testing the module is not the same as checking the policy

Suppose a team maintains a reusable module for AWS storage buckets. It accepts options for encryption, versioning, and access restrictions. Native tests can check that different inputs produce the expected resource settings. They can also verify that invalid inputs are rejected.

Tests can run against a plan or apply the configuration. Mocked providers allow some behaviour to be checked without creating cloud resources. That is useful for common modules shared across application teams: a change can be tested against several expected configurations before anyone depends on it.

But the method matters. A mock confirms how the module behaves under the values supplied by the test. It cannot prove that AWS will accept the configuration. An apply-based test can exercise real services, but then the pipeline needs controlled credentials, an isolated environment, and a cleanup procedure that accounts for failures.

The company’s rule prohibiting public storage is a separate concern. It must hold regardless of which module creates the bucket or which repository contains it. A central policy check can evaluate the proposed resource settings across projects. Tools such as OPA or Checkov may be useful here, depending on how the organization expresses and enforces its requirements.

In short, the tests answer different questions: Does the module produce the intended configuration? Does the configuration comply with the organization’s rules? And, when deployed, does it actually work?

What OpenTofu 1.13 added

OpenTofu 1.13 was released on September 29, 2026. One of its smaller additions was an experimental linting feature: extra checks for configuration patterns that might be confusing or worth improving, even when the configuration is otherwise valid.

For example, it can warn about an input variable without an explicit type or a local value that is never used. The initial rules can be enabled with:

tofu validate -lint=all

There are limits worth noting before putting this into CI. The initial core lint rules run against the root module, findings appear as warnings, and unknown lint-rule identifiers are ignored. Teams should not assume a successful command exit means a required lint policy was enforced. The feature is explicitly experimental and may change.

OpenTofu’s maintainers have also described a longer-term direction in which more checks could operate during validation, planning, and application. That is technically interesting because an IaC engine learns more about proposed resources as execution progresses. It is not, however, a delivered replacement for enterprise security and policy tools.

What to change in the pipeline

Start by examining what the existing CI job actually proves. validate confirms that the tool can interpret the configuration. A plan describes proposed changes, but does not certify them against every organizational requirement. Native tests can cover module behaviour, separate checks can enforce security policy, and selected changes may need isolated integration tests against real cloud services.

A small shared module and a production network change do not need identical pipelines. The checks should depend on the resources involved, the consequences of a mistake, and the requirements the team must meet. Ownership matters too: a policy provides limited independent assurance if the same change can quietly weaken both the infrastructure and the rules that approve it.

There is no need to migrate from Terraform to OpenTofu merely to obtain native tests. Terraform has offered them since version 1.6 in 2023. Teams already using OpenTofu can evaluate 1.13 linting in development, but should keep established controls in place while the feature is experimental.

The useful outcome is not fewer tools for their own sake. It is a pipeline whose passing result means that the checks relevant to the change were actually performed, and whose limitations are understood before production deployment.

References and further reading

Each source was opened and checked on 14 October 2026. OpenTofu linting is experimental, so recheck its documentation before relying on it.

1. OpenTofu: OpenTofu 1.13.0 release announcement. Published September 29, 2026. Release context and the experimental linting announcement.
2. OpenTofu: Linting documentation. Current experimental rules, invocation, warnings and limitations.
3. OpenTofu: Native testing. Testing semantics, mocks and plan and apply tests.
4. HashiCorp: Terraform tests. HashiCorp’s native testing documentation.
5. OpenTofu: A Vision for Built-in Linting. Published September 3, 2026. OpenTofu’s proposed future direction, not a description of fully delivered policy capabilities.