SDKs

Antithesis offers SDKs in a number of popular languages. These SDKs enable software to integrate with the Antithesis platform in various ways, and also provide a means of configuring and controlling your Antithesis tests.

All of our SDKs are designed to be able to run safely in production, as well as in the Antithesis environment. In most cases, they detect at program startup time whether they are running in the Antithesis environment, and if not then their functions turn into no-ops with minimal overhead, or into shims to appropriate standard library functions. The details of how this works differ a little bit from language to language, consult the language-specific SDK documentation for more information.

• Go
• Java
• C
• C++
• Python
• Javascript
• Rust
• .NET
• If you cannot use the SDK

Our SDKs offer three main categories of functionality:

Test properties

Our SDKs allow you to define test properties—either in your workload or in your actual software. Some of these properties resemble the conventional assertions that you are likely familiar with. But our SDK also allows you to define Sometimes assertions that are useful for checking the reachability of your code and for evaluating the quality of your tests. These properties will appear in your triage report and will be flagged as passing or failing in each of your test runs. Antithesis automatically collects detailed information and debugging artifacts at the moments when these assertions are triggered.

Randomness

Antithesis runs your tests in a deterministic simulation, so any random number generator (RNG) you consult will give the same sequence of answers in every test run. Since we wish to explore many possibilities over the course of each test, the Antithesis platform provides ways for your software—either your workload or your actual software—to request inputs that can be used in place of an RNG to make random decisions. The most straightforward way to do this is from the system random devices, which we override and replace with our own source of entropy. But the SDKs offer an alternative source that is both more convenient and more structured.

Use of SDK random functions is usually more convenient than opening and reading from system random devices. The SDK also offers higher-level, more “structured” random methods, for example the equivalent of the Python standard library’s random.choice(). These are not provided only for convenience, they also make it easier for the Antithesis platform to learn what sorts of inputs to provide.

Suppose you have a randomized workload that runs one of three tests, a(), b(), and c(). Suppose that test c() is ineffective, and rarely or never provokes interesting behavior in your system. If you use an SDK random function to decide which test to run, then over time Antithesis will learn that inputs which result in c() running are less fruitful, and will not provide them as often. But it is much easier to learn this if you tell Antithesis that you are making a choice between three options, as opposed to requesting a 64-bit number and computing its value modulo 3.

A corollary of this is that you should never take inputs returned by SDK random functions and use them to seed your own RNG, or store them to make a decision later. Either one of these anti-patterns makes it harder for Antithesis to learn to control your software, and defeats the purpose of using the SDK.

Lifecycle

Our SDKs provide methods that allow you to signal to the Antithesis environment that particular test phases have begun or ended. For example, if your system has a brittle or performance-intensive setup phase that should run without any fault injection, you may use the SDK to indicate when this setup has completed.

SDK Alternatives

The Antithesis SDK allows you to integrate with the Antithesis platform, and to configure it in your own code. If you cannot use our SDK, either due to policy, or because we have not yet produced an SDK in your language of choice, Antithesis offers a low-level fallback API.