How Antithesis works

What’s software testing really about?

Fundamentally, testing stateful software is about exploring a very large state space thoroughly enough – because some of those states are bugs.

Antithesis does this for you by running multiple copies of your software in a simulation environment that’s much more hostile than prod.

Exploring your software

Running in Antithesis is like an extreme version of chaos engineering, where everything is running in our fault-filled environment – your software, your client, your checkers. We throw random inputs at it (as though we’re fuzzing), while filling the environment with a wide range of faults.

We don’t just throw random inputs at the system – we have an intelligent guidance component (it uses RL, but you can tell your boss it’s AI) that constantly drives the platform to seek out new system states.

This creates a multiverse of branching execution paths in every Antithesis test. You can think of these as tens of thousands of alternate universes. In one universe, the network partitioned at time=t, and in many others, it didn’t.

Spotting bugs

To tell if a particular state is a bug, Antithesis relies on properties you define.

Instead of writing a vast test harness, you simply state that your system should have certain properties, and Antithesis checks whether they’re ever violated.

For example: You could write a hundred tests that each cover a different execution path and check whether your program crashes. But it’s simpler and more powerful to write a single statement that the program should never crash!

And because properties are long-lived, you never have to update your tests (unless you decide that you do want, e.g. to stop checking for race conditions).

Fixing bugs

The Antithesis environment is fully deterministic. This makes every bug we find perfectly reproducible, so you’ll never waste time trying to reproduce a flaky bug again.

Determinism enables us to provide detailed artifacts and powerful, one-of-a-kind debugging tools, like a deterministic time-traveling debugger.

What next?

Ready to get started? contact us at support@antithesis.com or ask on our Discord to request a container registry and credentials. Once you have those, you can dive right in/

  • Introduction
  • How Antithesis works
  • Using Antithesis documentation with AI
  • Get started
  • Test an example system
  • With Docker Compose
  • Build and run an etcd cluster
  • Meet the Test Composer
  • With Kubernetes
  • Build and run an etcd cluster
  • Meet the Test Composer
  • Setup guide
  • For Docker Compose users
  • For Kubernetes users
  • Product
  • Test Composer
  • Test Composer basics
  • Test Composer commands
  • How to check test templates 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
  • Multiverse debugging
  • Overview
  • 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
  • Optimizing for testing
  • Docker best practices
  • Kubernetes best practices
  • 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
  • White paper — How much does an outage cost?
  • Autonomous testing
  • Deterministic simulation testing
  • Property-based testing
  • Catalog of reliability properties for key-value datastores
  • Catalog of reliability properties for blockchains
  • Techniques to improve software testing
  • Test ACID compliance with a ring test