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:

Language-specific references:

  • Introduction
  • How Antithesis works
  • Get started
  • Test an example system
  • With Docker Compose
  • Build and run an etcd cluster
  • Meet the Test Composer
  • With Kubernetes
  • Build and run an etcd cluster
  • Meet the Test Composer
  • Setup guide
  • For Docker Compose users
  • For Kubernetes users
  • Product
  • Test Composer
  • Test Composer basics
  • Test Composer reference
  • How to check test templates locally
  • How to port tests to Antithesis
  • Reports
  • The triage report
  • Findings
  • Environment
  • Utilization
  • Properties
  • The bug report
  • Context, Instance, & Logs
  • Bug likelihood over time
  • Statistical debug information
  • Search dashboard & multiverse map
  • Multiverse debugging
  • Overview
  • The Antithesis multiverse
  • Querying with event sets
  • Environment utilities
  • Using the Antithesis Notebook
  • Cookbook
  • Tooling integrations
  • CI integration
  • Discord and Slack integrations
  • Issue tracker integration - BETA
  • Configuration
  • Access and authentication
  • The Antithesis environment
  • Optimizing for Antithesis
  • Docker best practices
  • Kubernetes best practices
  • Concepts
  • Properties and Assertions
  • Properties in Antithesis
  • Assertions in Antithesis
  • Sometimes Assertions
  • Properties to test for
  • Fault injection
  • Reference
  • Webhooks
  • Launching a test in Docker environment
  • Launching a test in Kubernetes environment
  • Launching a debugging session
  • Retrieving logs
  • SDK reference
  • Go
  • Tutorial
  • Instrumentor
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • Java
  • Tutorial
  • Instrumentation
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • C
  • C++
  • Tutorial
  • C/C++ Instrumentation
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • JavaScript
  • Python
  • Tutorial
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • Rust
  • Tutorial
  • Instrumentation
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • .NET
  • Tutorial
  • Instrumentation
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • Languages not listed above
  • Assert (reference)
  • Lifecycle (reference)
  • Assertion Schema
  • Instrumentation
  • Handling external dependencies
  • FAQ
  • Product FAQs
  • About Antithesis POCs
  • Release notes
  • Release notes