> ## Writing tests with the plugin

> Fetch the complete documentation index at: https://antithesis.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

---

The easiest way to write a driver in Antithesis is to have your coding agent write one using [the Antithesis plugin](https://github.com/antithesishq/antithesis-plugin). This page describes what your agent will implement.

If you have an existing Antithesis setup written by hand or with our [first generation agent skills](/docs/ai/skills/), your setup probably uses Antithesis' [test template framework](/docs/product/writing_tests/test_templates/).

## Overview

Our plugin will direct your coding agent to create a single *driver container* that gets deployed to Antithesis alongside your system. *The driver container must be excluded from faults* during testing, and the plugin will configure this for you.

The main process running in the container is a random action generator driven by [Hegel](https://www.hegel.dev) -- our open source property-based testing engine. The generator handles the core of property-based testing: data generation, shrinking, the example database, and so on. It reaches out to the SUT to trigger random actions.

All outputs from the SUT (including logs) get forwarded to the driver container. Listeners and checkers in the driver container check for violations of [common system properties](/docs/reference/default_properties/).

The driver container also contains logic that enables the workload to check eventual properties in the SUT -- eventual consistency, system recovery, etc.

### Systems with stateful clients

If the SUT has stateful clients, they will not run in the driver container. They will run in their own dedicated containers and the driver will reach out to trigger actions on them. This ensures the clients experience faults, as they would in production.

### Running outside Antithesis

A driver written by the plugin can be run outside Antithesis. This allows you to rapidly iterate by running locally to see what happens. You'll essentially see a single timeline rather than [the full multiverse of an Antithesis test](/docs/introduction/how_antithesis_works/#the-antithesis-multiverse).

### Code coverage

The plugin will focus on maximizing coverage of your system's code and state space.

In our experience, this approach almost always results in an initial workload that surfaces nasty bugs using only [common system properties pre-defined in Antithesis](/docs/reference/default_properties/), e.g. no unexpected crashes, container exits, or OOMs.

### Verifying the workload

The plugin will direct your coding agent to first run the workload against the SUT locally, iterating until full coverage is achieved.

It will then deploy the SUT and workload to Antithesis and launch a series of short runs to check instrumentation and coverage of code that runs only under faults (e.g. failovers). Once that's done, your driver is ready for use.