[nlavezzo]

I'd suggest taking a dive into the docs - there is quite a lot there that should address some of these questions.

That said, Antithesis doesn't require you to write manual tests, integration or otherwise. It requires your software system to be packaged in containers, which is fairly straightforward, and then requires a workload to be written which will emulate the normal functioning of the software system. So for example an e-commerce store would have product views, cart adds, checkouts, etc.

With this, Antithesis can start testing (running your workload, varying inputs, injecting faults, etc) the software and looking for violations of test properties. There are many (60+) test properties that come "out of the box" such as crashes, out of memory, etc. You can (and should) also define custom properties that are unique to your system, as this will surface more problems.

As your tests run, violations of test properties are reported, with lots of useful debug information included. Test runs that are particularly interesting can have a lot of extra analysis done, due to our ability to "rewind" and change inputs, get artifacts, add logging, etc.

[shuntress]

"Workloads" seem to be effectively equivalent to integration tests.

I don't mean to poke holes but I'm having trouble seeing the value add here.

If I have to deploy to some new environment anyways and I have to tailor the "Workloads" anyways why would I pay extra for vendor lock-in?

The type of devious bug this is promising to find would be something like:

"The DB silently drops timezone from Dates because of the column type. This results in unexpected data being returned for users in different timezones from the server"

I just don't see how repeatably calling the API with an expanding set of random inputs helps find something like that.

[catskul2]

IMO "Read the docs" is not a reasonable response to "what is it?"

Typically someone wants to know the most basic question before devoting time to diving into the docs.