Plan Checks
During the Lifecycle (config) and Refresh modes of a TestStep
, the testing framework will run terraform plan
before and after certain operations. For example, the Lifecycle (config) mode will run a plan before the terraform apply
phase, as well as a plan before and after the terraform refresh
phase.
These terraform plan
operations results in a plan file and can be represented by this JSON format.
A plan check is a test assertion that inspects the plan file at a specific phase during the current testing mode. Multiple plan checks can be run at each defined phase, all assertion errors returned are aggregated, reported as a test failure, and all test cleanup logic is executed.
- Available plan phases for Lifecycle (config) mode are defined in the
TestStep.ConfigPlanChecks
struct - Available plan phases for Refresh mode are defined in the
TestStep.RefreshPlanChecks
struct - Import mode currently does not run any plan operations, and therefore does not support plan checks.
Built-in Plan Checks
The terraform-plugin-testing
module provides a package plancheck
with built-in plan checks for common use-cases:
Check | Description |
---|---|
plancheck.ExpectEmptyPlan() | Asserts the entire plan has no operations for apply. |
plancheck.ExpectNonEmptyPlan() | Asserts the entire plan contains at least one operation for apply. |
plancheck.ExpectResourceAction(address, operation) | Asserts the given resource has the specified operation for apply. |
plancheck.ExpectUnknownValue(address, path) | Asserts the specified attribute at the given resource has an unknown value. |
plancheck.ExpectSensitiveValue(address, path) | Asserts the specified attribute at the given resource has a sensitive value. |
Examples using plancheck.ExpectResourceAction
One of the built-in plan checks, plancheck.ExpectResourceAction
, is useful for determining the exact action type a resource will under-go during, say, the terraform apply
phase.
Given the following example with the random provider, we have written a test that asserts that random_string.one
will be destroyed and re-created when the length
attribute is changed:
Another example with the time provider asserts that time_offset.one
will be updated in-place when the offset_days
attribute is changed:
Multiple plan checks can be combined if you want to assert multiple resource actions:
Custom Plan Checks
The package plancheck
also provides the PlanCheck
interface, which can be implemented for a custom plan check.
The plancheck.CheckPlanRequest
contains the current plan file, parsed by the terraform-json package.
Here is an example implementation of a plan check that asserts that every resource change is a no-op, aka, an empty plan:
And example usage: