Overview

This section covers what it looks like to use Antithesis in your day to day: when to run Antithesis tests, how to automate your testing, and what to do when you find something “interesting” in the results.

This section assumes you have a working test, so if you haven’t run a test yet, check out the setup guide and start a test run.

How often should I test?

A bug is cheapest to fix in the moment it’s written because the code is fresh in your memory and the fix is often to revert the change and think a little harder about how to do it correctly.

As time passes, this bug becomes harder to find, until your customers find it for you. Now the bug’s much more expensive.

The easiest way to deal with this is to shrink the gap between a bug being introduced and finding it in testing. Antithesis fits seamlessly in your development lifecycle so you can continuously test during your development and deployment cycle.

Development cycle testing: You should test feature branches as you’re working on them, and before merging to main. Think of these tests as a combination of smoke test, regression test, and a quick sanity check. To support this workflow, Antithesis provides streaming access to test logs (and soon, full test results) via CLI and API, so you get results within minutes.

Deployment cycle testing: You should also run a longer test against your main development branch on a nightly basis. This provides thorough exploration of your system, and surfaces hard-to-find bugs the day they’re introduced.

You can automate these tests by scheduling regular Antithesis test runs either via the CI integration or via a custom cron job.

You found a bug. Now what?

If (when) you find a bug, Antithesis provides you with powerful debugging tools. This page provides an overview of how to triage a failure and the tools Antithesis provides to help you debug. Once you think you’ve fixed the failure, you can start a new test run and watch the property that was failing.