Testing & CI/CD Basics

Relax. We'll talk through this in plain words — no textbook voice.

What you'll walk away with

Understand Testing & CI/CD Basics without any of the intimidation
Get hands-on running terraform commands and HCL code yourself
Apply this concept in a real project right away

Let's think about it this way for a second

`terraform validate` checks for syntax errors (typos, wrong argument names) locally, without needing to call the cloud API — handy as a quick sanity check before committing. `terraform fmt` auto-fixes code style (indentation, spacing) to the standard format — it helps keep every team member's code style consistent. It's common to set up a CI/CD pipeline (GitHub Actions) to auto-run `terraform plan` on every pull request and post it as a comment — team members can then see exactly 'what's about to change' right on the PR, while `apply` only runs after merge (or after manual approval).

Let's connect this to a real scenario

If a GitHub Actions workflow file runs `terraform fmt -check` (fails on bad formatting), `terraform validate` (fails on syntax errors), and `terraform plan` (change preview) as separate steps, every push a developer makes triggers an automatic check, catching human error early.

terraform validate does a quick local check for syntax/argument errors
terraform fmt auto-fixes code style (for team-wide consistency)
A CI/CD pipeline auto-runs plan on every PR, and only runs apply after merge/approval

Let's look at it together

yaml

# .github/workflows/terraform.yml (simplified)
name: Terraform
on: [pull_request]
jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform fmt -check
      - run: terraform validate
      - run: terraform plan

You should see

$ terraform fmt -check
$ terraform validate
Success! The configuration is valid.

$ terraform plan
Plan: 2 to add, 0 to change, 0 to destroy.

5-minute try-it

Run both `terraform fmt -check` and `terraform validate` on a local config folder — deliberately mess up the code style first and see how `fmt` auto-fixes it.

A quick word of caution

Store your CI/CD pipeline's credentials (AWS access keys) properly as repository secrets — never hardcode them in the workflow file.

Easy traps

Setting up `terraform apply` to auto-run in a CI/CD pipeline without an approval step — this risks accidentally applying to production resources
Thinking `terraform validate` also catches provider credential/network errors — validate only does syntax/type checks, real API errors only show up at plan/apply time

Now try it yourself

Run both `terraform fmt -check` and `terraform validate` on a local config folder — deliberately mess up the code style first and see how `fmt` auto-fixes it.

You'll know it worked when: $ terraform fmt -check $ terraform validate Success! The configuration is valid. $ terraform plan Plan: 2 to add, 0 to change, 0 to destroy.