We are having problems in testing routes that modify the data in our API. For example the test that deletes a resource will fail if run the second time.
Also due to business logic you can't create or delete some resources via the API (as they are created by other triggers, or as a user you can't delete data but only archive).
Also you can't create resources with a particular id, it's generated by the API, so it can be hard to test some special situations and not all test suits permit getting the data from other requests to reuse later on. And this would also break running tests independently as it will create dependency between tests.
Also redeploying the whole application for one test is not ideal, as it will slow down the whole development of our application.
So what would be the best approach for re-seeding the db? Was thinking to add a route like:
But that breaks the responsibility principles, that the API shouldn't be responsible for testing and that this should be the job of the tests.
The API/web app has a complicated stack based on more docker microservices, events queued in rabbitMQ, elasticsearch, mongodb, external file storage, third party authentification, docker, kubernets, horizontal scalability, etc.
So it's not just a DB to mock, and would like to have the testing environment as close to production as possible. Also I would like to be able to run and debug the tests from the local env, as I'm creating them. As having to deploy the whole stack again just to run and debug one test would a massive overkill and would slow down development a lot. Also, as a nice to have, we would like to use ATDD.