Creating test templates

This page explains how to create test templates, and how Antithesis recognizes and runs them.

See test commands for details of available test commands.

Creating a test template

A test template is a directory that lives under /opt/antithesis/test/v1/ and contains scripts called test commands. For convenience, we sometimes refer to /opt/antithesis/test/v1/ as the “test directory”.

Here’s an example file structure:

/opt/antithesis/test/v1/               ← test directory
├── main/                              ← a test template
    ├── first_setup.py
    ├── parallel_driver_produce.py
    ├── parallel_driver_consume.py
    ├── serial_driver_compact.sh
    ├── anytime_health.py
    ├── eventually_verify.py
    ├── finally_consistency.sh
    ├── helper_utils.py                ← ignored by Antithesis (helper_ prefix)
    └── helper_modules/                ← ignored by Antithesis (helper_ prefix)
        └── kafka_client.py

You can place your test templates under /opt/antithesis/test/v1/ inside any of your containers, but we recommend placing it in a dedicated container rather than in your system containers.

Multiple containers can also share a test template, see below.

Any container with test templates must be kept running (e.g., via sleep infinity in the entrypoint). Do not use a test command as the container entrypoint.

Using multiple test templates

You can add multiple test templates under /opt/antithesis/test/v1/. By placing multiple test templates in the test directory, you can use different testing strategies during a single Antithesis run.

Here’s an example:

/opt/antithesis/test/v1/
├── basic/                            ← simple producer/consumer tests
│   ├── first_create_topic.py
│   ├── parallel_driver_produce.py
│   └── parallel_driver_consume.py
├── transactional/                    ← transaction-focused tests
│   ├── first_setup_tx.py
│   ├── parallel_driver_tx_write.py
│   └── finally_tx_verify.py
└── stress/                           ← high-throughput stress test
    └── singleton_driver_load.py

Antithesis selects exactly one template per execution history. Test commands in basic/ will never run alongside test commands in transactional/ or stress/.

This means all commands in a single test template should be compatible with each other, but you can include incompatible commands in different test templates.

Sharing test templates across multiple containers

If containers client-a and client-b both have a directory called /opt/antithesis/test/v1/main/, Antithesis treats both instances of main as a single test template with commands spread across both containers. Each command runs inside the container where it is defined.

Helper files

Subdirectories and files with a helper_ prefix in their name are ignored by Antithesis. Use this prefix for shared libraries, utility modules, and configuration files that your test commands require.

  • Introduction
  • How Antithesis works
  • Using Antithesis with AI
  • Get started
  • Test an example system
  • With Docker Compose
  • Build and run an etcd cluster
  • Add a test template
  • With Kubernetes
  • Build and run an etcd cluster
  • Add a test template
  • Setup guide
  • For Docker Compose users
  • For Kubernetes users
  • Product
  • Test templates
  • Creating test templates
  • Test commands
  • How to check a test template locally
  • How to port tests to Antithesis
  • Test launchers
  • Reports
  • The triage reports
  • Findings
  • Environment
  • Utilization
  • Properties
  • The bug reports
  • Context, Instance, & Logs
  • Bug likelihood over time
  • Logs Explorer & multiverse map
  • Debugging
  • Multiverse debugging
  • Advanced mode
  • The Antithesis multiverse
  • Querying with event sets
  • Environment utilities
  • Using the Antithesis Notebook
  • Cookbook
  • Tooling integrations
  • CI integration
  • Discord and Slack integrations
  • Issue tracker integration - BETA
  • Configuration
  • Access and authentication
  • The Antithesis environment
  • Best practices
  • Docker best practices
  • Kubernetes best practices
  • Optimizing for testing
  • Concepts
  • Properties and Assertions
  • Properties in Antithesis
  • Assertions in Antithesis
  • Sometimes Assertions
  • Properties to test for
  • Fault injection
  • Reference
  • Webhooks
  • Launching a test
  • Launching a debugging session
  • Webhook parameters
  • SDK reference
  • Define test properties
  • Generate randomness
  • Manage test lifecycle
  • Assertion catalog
  • Coverage instrumentation
  • Go
  • Instrumentor
  • Tutorial
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • Java
  • Using the SDK
  • Building your software
  • Tutorial
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • C
  • C++
  • C/C++ Instrumentation
  • Tutorial
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • JavaScript
  • Python
  • Tutorial
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • Rust
  • Instrumentation
  • Tutorial
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • .NET
  • Instrumentation
  • Tutorial
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • Languages not listed above
  • Assert (reference)
  • Lifecycle (reference)
  • Assertion Schema
  • Handling external dependencies
  • FAQ
  • Product FAQs
  • About Antithesis POCs
  • Release notes
  • Release notes
  • General reliability resources
  • Reliability glossary
  • Techniques for better software testing
  • Autonomous testing
  • Deterministic simulation testing
  • Property-based testing
  • White paper — How much does an outage cost?
  • Catalog of reliability properties for key-value datastores
  • Catalog of reliability properties for blockchains
  • Test ACID compliance with a ring test