Currently, the integration test suite reads & writes to the configured database in the .env file. This is undesirable for many reasons -- two of the main ones being:
It makes the results non-deterministic; re-running the test suite a second time, will not even pass because of the pre-existing data
It will make writes with test data into the real database; resulting in actual user and score creations
Instead, when the integration test suite is starting up, we should spin up a new database, run the migrations against it, use that during tests, then spin it down after the test suite has run. Every new run of the test suite should have it's own isolated/new temporary database to work with.
This is a super high value task -- as it paves the way for our integration test suite to grow in reliability and re-usability!
Currently, the integration test suite reads & writes to the configured database in the
.envfile. This is undesirable for many reasons -- two of the main ones being:Instead, when the integration test suite is starting up, we should spin up a new database, run the migrations against it, use that during tests, then spin it down after the test suite has run. Every new run of the test suite should have it's own isolated/new temporary database to work with.
This is a super high value task -- as it paves the way for our integration test suite to grow in reliability and re-usability!