4 ms·
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: fo
by quickthrower2 4y ago
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 4y ago> 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 4y agoThanks, 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.