| A Comprehensive Guide to Testing in Terraform: Keep your tests, validations, checks, and policies in order |
- CLI validation command ->
terraform validate - Custom conditions
- Variable validation -> add
validation blocks nested inside of variable blocks  - Validations that run before or after changes are applied to a resource -> add
precondition or postcondition blocks nested inside of a lifecycle block in a resource or data source  - Output validation -> add a
precondition block nested inside of output blocks 
- Test framework
- Test files use the
.tftest.hcl file ending - By default, all test files stored in the same directory as your module, or stored in a
tests directory, are run when you issue the terraform test command - A test file consists of one or more
run blocks. Each run block should be thought of as a test. A run block includes a number of arguments and blocks to configure what the test should do. Each test executes a command, which is either plan or apply (default) 
- Checks
- The
check block is ideal for validations you want to make that should not stop a plan and apply from finishing (if a check fails the deployment will still continue) - A
check block can include at most one scoped data block, and one or more assert blocks. Each assert block has a condition that evaluates to true or false, and an error_message that is displayed if the assertion fails. The purpose of the scoped data block is to read data about a resource, or perhaps an external website, that you want to include in the check 
- Policies
- OPA vs HashiCorp Sentinel
- The purpose of policies with Terraform is to validate that the changes you are introducing follow rules defined by you or your organization
|