Does anybody else use a pattern like this?
I have one parent container which runs all of the testing code. The tests orchestrate the other containers inside it. Each test starts and stops all the required services every time.
So, for example - the test running in the test container runs “compose up” - which runs the playwright server, the app service I’m testing, the database server, etc. It would seed the database with fixtures and connect to the playwright service in set up and then begin.
It would then use the playwright service to load the website, click, etc.
Afterwards the test runs compose down and the next test is run.
- It minimizes the “works on my machine” problems.
- Cross platform - this can run the same end to end tests on windows, linux, mac and on CI or desktop without really changing anything.
- Doesn’t make a mess on the system you run it on - all the dependencies for the tests and the app are kept in one container and volume which can be set up with one script.
- I can do TDD with these tests.
- They can be parallelized easily - unlike end to end tests running against a staging server.
- The application is kept completely isolated from the testing code. No testing tools need to be installed inside the container that you will also want to deploy to prod.
I figure that most projects probably still need some tests running against a staging server to catch infrastructure-related bugs, but a lot of tests running against deployed servers could be shift lefted into a hermetically sealed end to end test like this.
This kind of pattern might have a name. If it does I don’t know what it is.