Compose your first test

Once your system is running in Antithesis, you’ll need to add a test template – a way to exercise the functionality of your system as a whole.

We use the term “test template” to mean something broader than most people do when they think of “tests.” A test template in Antithesis is a guide that the system uses to generate thousands of test cases that will run over a multitude of system states.

Because autonomous testing requires a slightly different mindset than the example-based approach most developers are used to, writing an effective test template can be challenging (we know this from experience!). Antithesis therefore offers a test composer that makes it easy to get started with tests you already have, then strengthen them over time.

In this guide, we’ll show you how to get started with a simple test. For more information about how to take advantage of autonomous testing, check out our test composer reference.

Setup

Before running any tests, Antithesis initializes your software and its dependencies with a docker compose file from a config image. Once your system is up and running, you should emit a SetupComplete message using our SDKs, or by writing a special JSON message. Once the SetupComplete message is emitted, the test composer will begin running test commands and injecting faults.

Test commands

The simplest possible test template consists of a single test directory containing a single test command.

The test directory is a subdirectory of /opt/antithesis/test/v1 in any of your containers. Many customers prefer to put the tests in a standalone container (to simulate a client) but the test composer will detect test directories in any container started in the Antithesis system. For this guide, we’ll use /opt/antithesis/test/v1/quickstart.

A test command is a specially-named executable (e.g. a shell script, python script, or executable binary) nested directly under the test directory. The command will be run inside the container where it is defined, and typically calls APIs on the system under test and asserts various properties.

Many customers start by directly porting one or more of their existing integration tests. To do this, all you need to do is make your integration test a test command – singleton_driver_integration_test.sh in the /opt/antithesis/test/v1/quickstart directory.

Over the course of your test, the test composer will run different combinations of test commands. The test composer expects command names to include special prefixes that tell it how a command expects to run. In our example, the singleton_driver_ prefix says that this test command should be run by itself, while Antithesis is subjecting the system to faults.

Once you’ve added your existing integration test to your container as a singleton_driver_ nested in a test directory, you’re done!

Congratulations – you’re ready to run your first Antithesis test. But this example only scratches the surface of what Antithesis testing can do. To find out how to strengthen your testing, check out our test composer reference and contact us if you have questions.

Note

If you choose to add your tests to a standalone container, the container’s entry point should not be a test command. Instead, use something that will keep the container running (sleep infinity works well).