[quickthrower2]

Nice! How do you deal with:

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

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

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

4. GDPR laws

5. Authentication

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

[vedant_ag]

> 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.

[quickthrower2]

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.