Timeline for How to reset state of exernal services when running Acceptance tests
Current License: CC BY-SA 4.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 9, 2022 at 21:56 | comment | added | Frax | I see. The coupling can be perhaps mitigated if the same scripts can be used to set up both the test and production environment - though this may be challenging to set up, depending on your starting point. In the ideal case the only difference would be a small setup file giving the server names and maybe some credentials. That way the setup is also made a part of the service, hence so the implementation details are "legitimately" used there. | |
| Feb 9, 2022 at 13:56 | comment | added | berkes | I've (tried to) set up the entire system so that persistence and state is an implementation detail for the service that uses it. No services can reach into eachothers state (db, files etc). Which is one of the reasons I'm a bit unconfortable that my tests do need to reach into them. I like the idea of just resetting the entire service. It does introduce a coupling with the infrastructure: resettng a docker is different from resetting an AWS RDS, or, in my case a Render (.com) service. But I guess that is unavoidable. | |
| Feb 9, 2022 at 1:16 | history | answered | Frax | CC BY-SA 4.0 |