Integration testing strategies in Terraform - Step-by-Step Execution

Process Flow - Integration testing strategies

Write Terraform code

↓

Deploy infrastructure

↓

Run integration tests

↓

Check test results

↓

Confirm infra

↓

Repeat tests

Integration testing in Terraform means deploying real infrastructure and running tests to check if components work together correctly.

Execution Sample

Terraform

terraform init
terraform apply -auto-approve
run integration tests
terraform destroy -auto-approve

This sequence deploys infrastructure, runs tests to check integration, then cleans up resources.

Process Table

Step	Action	Terraform Command/Tool	Result	Next Step
1	Initialize Terraform	terraform init	Terraform ready to deploy	terraform apply
2	Deploy infrastructure	terraform apply -auto-approve	Resources created in cloud	Run integration tests
3	Run integration tests	custom test scripts	Tests check resource interaction	Check test results
4	Check test results	test output	Pass or Fail	If Pass: Confirm infra; If Fail: Fix code & retry
5	Confirm infrastructure	manual or automated check	Infrastructure works as expected	terraform destroy
6	Fix code & retry	edit Terraform code	Code updated	Repeat from terraform apply
7	Destroy infrastructure	terraform destroy -auto-approve	Resources removed	End

💡 Tests pass and infrastructure is confirmed, or code is fixed and tests rerun until success.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Terraform State	empty	resources created	resources exist	test pass/fail recorded	resources destroyed
Test Status	not run	not run	running	pass or fail	completed

Key Moments - 3 Insights

Why do we need to deploy real infrastructure for integration testing?

Because integration tests check if different parts work together in a real environment, not just in code. See execution_table step 2 and 3.

What happens if tests fail after deployment?

You fix the Terraform code and rerun deployment and tests until they pass, as shown in execution_table steps 4 and 6.

Why destroy infrastructure after tests?

To avoid extra costs and keep the environment clean. This is step 7 in the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what is the result after running 'terraform apply -auto-approve'?

A Terraform ready to deploy

B Resources created in cloud

C Resources removed

D Tests pass or fail

💡 Hint

Check Step 2 in the execution_table under Result column.

At which step do integration tests run according to the execution_table?

A Step 3

B Step 1

C Step 5

D Step 7

💡 Hint

Look at Step 3 in the execution_table under Action column.

If tests fail, what is the next action based on the execution flow?

A Destroy infrastructure immediately

B Confirm infrastructure works

C Fix code and retry deployment

D Skip tests and proceed

💡 Hint

See the branch after 'Check test results' in concept_flow and Step 6 in execution_table.

Concept Snapshot

Integration testing with Terraform:
1. Write Terraform code
2. Deploy real infrastructure (terraform apply)
3. Run tests to check resource interaction
4. Fix code if tests fail
5. Destroy infrastructure after tests
Key: Test real deployed resources, not just code.

Full Transcript

Integration testing strategies in Terraform involve deploying actual cloud resources using 'terraform apply', then running tests to verify that these resources work together correctly. If tests pass, the infrastructure is confirmed; if not, the Terraform code is fixed and redeployed. After testing, resources are destroyed to avoid costs. This cycle repeats until tests pass, ensuring reliable infrastructure integration.

Practice

1. What is the main goal of integration testing in Terraform?

easy

A. To create user interfaces for cloud services

B. To check if multiple cloud resources work together correctly

C. To deploy resources without any errors

D. To write Terraform code faster

Solution

1. Step 1: Understand integration testing purpose

   Integration testing focuses on verifying that different parts work together as expected.

2. Step 2: Apply this to Terraform

   In Terraform, it means checking if cloud resources connect and interact properly.

3. Final Answer:

   To check if multiple cloud resources work together correctly -> Option B

4. Quick Check:

   Integration testing = check resource cooperation [OK]

Hint: Integration testing checks resource cooperation, not code speed [OK]

Common Mistakes:

• Confusing integration testing with deployment
• Thinking it tests only single resources
• Assuming it improves coding speed

2. Which Terraform feature helps share data between resources during integration testing?

easy

A. Terraform variables

B. Terraform modules

C. Terraform providers

D. Terraform outputs

Solution

1. Step 1: Identify data sharing methods in Terraform

   Terraform outputs expose values from one resource to be used elsewhere.

2. Step 2: Match with integration testing needs

   Outputs allow tests to verify connections by passing resource info between them.

3. Final Answer:

   Terraform outputs -> Option D

4. Quick Check:

   Outputs share data between resources [OK]

Hint: Outputs expose resource data for testing connections [OK]

Common Mistakes:

• Confusing variables with outputs
• Thinking providers share data
• Assuming modules handle data passing

3. Given this Terraform snippet, what will output "db_endpoint" show after apply?

resource "aws_db_instance" "db" {
  identifier = "mydb"
  endpoint   = "mydb.example.com"
}

output "db_endpoint" {
  value = aws_db_instance.db.endpoint
}

medium

A. "mydb"

B. "aws_db_instance.db.endpoint"

C. An error because endpoint is not a valid attribute

D. "mydb.example.com"

Solution

1. Step 1: Understand resource attributes

   The resource aws_db_instance.db does not have a valid attribute named endpoint accessible directly; endpoint is an attribute returned by AWS after creation but is accessed differently.

2. Step 2: Check output value

   Since endpoint is not a valid attribute in this context, Terraform will raise an error when trying to output it.

3. Final Answer:

   An error because endpoint is not a valid attribute -> Option C

4. Quick Check:

   Outputting invalid attribute causes error [OK]

Hint: Not all resource attributes are directly accessible; check docs [OK]

Common Mistakes:

• Thinking output shows attribute value without validation
• Assuming endpoint is valid attribute
• Confusing identifier with endpoint

4. You wrote a Terraform test to check resource connections but it fails with a dependency error. What is the likely cause?

medium

A. Missing explicit resource dependency using depends_on

B. Using outputs instead of variables

C. Applying in the wrong cloud region

D. Incorrect provider version

Solution

1. Step 1: Identify cause of dependency errors

   Terraform needs explicit dependencies to know resource creation order.

2. Step 2: Check for missing depends_on

   If depends_on is missing, Terraform may try to create resources in wrong order causing errors.

3. Final Answer:

   Missing explicit resource dependency using depends_on -> Option A

4. Quick Check:

   Dependency errors = missing depends_on [OK]

Hint: Add depends_on to fix resource creation order errors [OK]

Common Mistakes:

• Blaming outputs for dependency errors
• Ignoring resource creation order
• Assuming provider version causes dependencies

5. You want to run integration tests on Terraform resources without affecting production. Which strategy is best?

hard

A. Use isolated test environments with separate state files

B. Run tests directly on production resources

C. Disable Terraform state locking during tests

D. Use the same state file but different workspaces

Solution

1. Step 1: Understand risk of testing on production

   Testing on production can cause unintended changes or downtime.

2. Step 2: Choose isolated environments

   Using separate environments and state files keeps tests safe and independent from production.

3. Final Answer:

   Use isolated test environments with separate state files -> Option A

4. Quick Check:

   Isolated environments prevent production impact [OK]

Hint: Always isolate test environments to protect production [OK]

Common Mistakes:

• Testing directly on production
• Disabling state locking unsafely
• Using same state file for tests and prod