> 1. Statefulness: simple example, api call that returns a query from the DB that has a high transaction load

We natively handle API and DB calls.

> 2. Non determinism: for example returns a random number, guid or a time

This is a bit tricky. We run the same test multiple times, and ignore the changing fields.

> 3. Privacy requirements for certifications or legislation that mean private data cannot be used in a test environment. > > 4. GDPR laws

We anonymise *any* private data before storing it for replay.

> 5. Authentication

We capture auth headers, and mock auth server responses.

> I presume this is more microservice friendly and monolith unfriendly. But that is probably a reason on the pro side of smaller, bounded services.

Currently yes. APIs can be easily tested. Tests for function calls will require user configuration.

Thanks, they are great answers. I think as always you can’t expect to magically throw a test tool at the application. You need some effort to make it testable. Moving out auth and anything else stateful to another service that can be mocked helps.