Infrastructure Testing — Molecule, Test Kitchen, InSpec, Chainsaw

Wed, 03 Jun 2026 00:00:00 +0000

Infrastructure code needs testing like application code does. The tools here cover different layers: role testing, integration testing, compliance checking, and Kubernetes end-to-end testing.

Molecule — Ansible role testing

Molecule is the standard testing framework for Ansible roles and playbooks. It manages the full test lifecycle: spin up instances, apply the role, verify the result, tear everything down.

Stages:

molecule create # spin up test instances (Docker, Podman, EC2, etc.)
molecule converge # apply the role/playbook
molecule verify # run assertions
molecule destroy # clean up
molecule test # full cycle in sequence

Drivers control where instances run — Docker or Podman for local development, EC2 or other cloud providers for closer-to-production testing.

Verifiers run assertions after converge. The default is Ansible itself (run a playbook of assertions), but Testinfra (pytest-based) and Goss are popular alternatives.

A minimal molecule/default/molecule.yml:

driver:
 name: docker

platforms:
 - name: instance
 image: ubuntu:22.04

provisioner:
 name: ansible

verifier:
 name: ansible

Wire into CI: molecule test runs the full cycle and exits non-zero on failure.

Test Kitchen — integration testing for infrastructure

Test Kitchen (kitchen.ci) is an integration testing framework originally built for Chef but now multi-platform. It creates instances, applies configuration, runs a verifier, and destroys.

Drivers: Docker, Vagrant, and cloud providers (EC2, GCP, Azure). Plugins also exist for Ansible (kitchen-ansible) and Terraform (kitchen-terraform).

Verifiers: InSpec (most common), Busser.

A kitchen.yml for a Chef cookbook:

driver:
 name: docker

provisioner:
 name: chef_zero

verifier:
 name: inspec

platforms:
 - name: ubuntu-22.04

suites:
 - name: default
 verifier:
 inspec_tests:
 - test/integration/default

kitchen list # show instance state
kitchen converge # apply provisioner
kitchen verify # run verifier
kitchen test # full cycle

Test Kitchen is less commonly adopted outside Chef shops, but the multi-platform support means it can be useful for testing across providers in one framework.

InSpec — compliance testing as code

InSpec (now Progress Chef InSpec) is a compliance testing framework. You write assertions about the state of a system — packages installed, ports listening, file permissions, user accounts — in a Ruby DSL. InSpec executes them locally, over SSH, against Docker containers, or against cloud APIs.

describe package('nginx') do
 it { should be_installed }
end

describe service('nginx') do
 it { should be_running }
 it { should be_enabled }
end

describe port(80) do
 it { should be_listening }
end

describe file('/etc/nginx/nginx.conf') do
 its('mode') { should cmp '0644' }
end

Profiles are the distributable unit — a collection of controls with metadata. The InSpec community maintains profiles for CIS benchmarks, DISA STIGs, and other compliance standards.

Where it fits: compliance auditing, security baselines, post-deploy verification. Wired into CI as a final gate or run on a schedule against production.

inspec exec path/to/profile --target ssh://user@host
inspec exec path/to/profile --target docker://container-id

Chainsaw — Kubernetes e2e testing

Chainsaw is a declarative end-to-end testing framework for Kubernetes. Originally from the Kyverno project, now standalone. Write test scenarios in YAML — apply manifests, assert on resource state, clean up — without writing Go or any test framework code.

Particularly useful for testing Kubernetes operators, controllers, and admission webhooks: the things that are hard to unit test because they depend on the Kubernetes API.

apiVersion: chainsaw.kyverno.io/v1alpha1
kind: Test
metadata:
 name: basic-deployment
spec:
 steps:
 - name: create deployment
 try:
 - apply:
 resource:
 apiVersion: apps/v1
 kind: Deployment
 metadata:
 name: test-app
 spec:
 replicas: 2
 # ...
 - assert:
 resource:
 apiVersion: apps/v1
 kind: Deployment
 metadata:
 name: test-app
 status:
 readyReplicas: 2
 - name: cleanup
 try:
 - delete:
 ref:
 apiVersion: apps/v1
 kind: Deployment
 name: test-app

chainsaw test ./tests/

vs Terratest for Kubernetes: Terratest requires Go code; Chainsaw is YAML. For testing Kubernetes resources and operators specifically, Chainsaw is simpler to write and maintain.

Terratest — Go-based infrastructure testing

Covered in the Terraform page. The short version: Go tests that deploy real infrastructure, run assertions via cloud SDKs, then tear it down. The most complete integration testing approach for Terraform modules — and the highest cost in setup and test execution time.

Choosing

Tool	Best for	Language
Molecule	Ansible role testing	YAML + Python/Ansible
Test Kitchen	Multi-platform integration testing	YAML + Ruby (InSpec)
InSpec	Compliance assertions, security baselines	Ruby DSL
Chainsaw	Kubernetes operators and controllers	YAML
Terratest	Terraform module integration testing	Go

Ansible

Mon, 01 Jan 2024 00:00:00 +0000

Ansible is an open-source automation tool for configuration management, application deployment, and orchestration. The key selling point: it’s agentless — you push from a control machine over SSH, no daemon running on managed hosts.

Why Ansible

Free and open source — Red Hat maintains it, commercially supported via Ansible Automation Platform (formerly Tower)
Agentless — no software to install on managed nodes; plain SSH is enough
Simple — playbooks are YAML, readable without special knowledge
Flexible — works on servers, cloud platforms, network devices, and bare-metal

What it does

Configuration management — define what state a system should be in; Ansible gets it there and keeps it there.

Application deployment — deploy multi-tier applications with a playbook; let Ansible figure out the ordering and state transitions.

Orchestration — coordinate complex workflows across databases, networks, front-end and back-end services in the right order.

Security and compliance — enforce firewall rules, user policies, and security baselines across all hosts from a single playbook run.

Cloud provisioning — provision infrastructure on AWS, Azure, GCP, OpenStack, or bare-metal with the same tooling.

Architecture

Modules — small programs pushed to nodes over SSH, executed, then removed. Ansible ships with 750+ modules for packages, services, files, cloud APIs, and more.

Plugins — extend Ansible’s core: connection types, callbacks, caching, filtering. Write your own or use community plugins.

Inventory — a file (INI or YAML) listing all managed hosts, their IPs, groups, and variables. Can also pull dynamic inventory from AWS, GCP, Azure, etc.

Playbooks — YAML files describing tasks to run on which hosts. The core unit of work. Each play maps a group of hosts to a set of tasks; each task calls a module.

APIs — extend connection transports beyond SSH (WinRM for Windows, network device APIs, etc.).

Ansible Automation Platform

Red Hat’s commercial wrapper around Ansible. Adds a web UI, RBAC, job scheduling, audit logging, and a workflow editor. Worth it once you have multiple teams running automation.

Where Ansible still excels

Network device configuration is the clearest remaining stronghold. Ansible has mature modules for switches, routers, and firewalls (Cisco IOS, Arista EOS, Juniper JunOS, and many others) and the agentless SSH model works well for network gear that can’t run an agent. For network automation, Ansible is still state of the art.

For server configuration management — the original use case — most teams should consider moving to other models. Terraform manages provisioning, container images handle application configuration (immutable infrastructure), and Kubernetes operators handle runtime state. The gap Ansible used to fill is smaller.

The configuration management landscape

Ansible is one of several tools in this space. The others worth knowing:

Salt (SaltStack) — agent-based, event-driven, fast for large fleets. More complex than Ansible.
Puppet — agent-based, declarative DSL, strong in enterprise. Puppet Forge has a large module library.
Chef — agent-based, Ruby DSL, infrastructure as code before the term was common. Less common now.

See Configuration Management — Puppet, Chef, Salt for a full comparison.

All four predate the Kubernetes era. Ansible has survived best because it is agentless and YAML-based — lower barrier. The others are still found in large enterprise environments with long-lived infrastructure.

Ansible on Backend Engineering Strategy Tools