Properties and Assertions

Even if you’re unfamiliar with the concept of software properties, you’re already using them to reason about your software – because you know what your system ought to do.

Should your software crash? That’s a property. Should your system run out of memory? That’s another. Should your database return the latest write? That’s a property too.

Traditional software testing involves writing a vast test harness that hopefully ensures your system has the properties promised in your documentation or system spec. But it does this in a roundabout way – by checking a large number of pre-written cases which together embody the properties you care about. If you’re very lucky, your tests include the right number and right kind of cases to ensure that your properties always hold.

Antithesis takes a different approach: property-based testing. You directly state how your system ought to behave – that it should have certain properties – and Antithesis runs your system in a multitude of situations to see if they’re ever violated. You express these properties by including assertions in your software using our SDKs (similar to the programming assertions you might have used).

There are significant advantages to this approach, which we outline in How Antithesis Works. In this section, we explain how the platform handles properties and assertions, to build your mental model of how to test your software in Antithesis.

In this section:

• Properties in Antithesis
• Assertions in Antithesis
• Properties to Test For
• Sometimes Assertions

Language-specific references:

• Go Assertions
• Java Assertions
• C++ Assertions
• Python Assertions
• Rust Assertions
• Languages not listed above