Comment by didiskaka
12 days ago
> operate this? Do you spin up a new postgres DB for each unit test?
Generally I've seen a new database (schema in other dbs?) in postgres that is for testing, i.e "development_test" vs "development". The big thing is to wrap each of your tests in a transaction which gets rolled back after each test.
> maintain this, eg have good, representative testing data lying around
This is much harder. Maintaining good seed data - data that covers all the edge cases - is a large amount of work. It's generally easier to leave it up to each test to setup data specific to their test case, generalizing that data when possible (i.e if you're testing login endpoints, you have all your login test cases inherit from some logic specific data setup, and they can tweak as needed from there). You will end up with duplicated test setup logic. It's not that bad, and often you don't really want to DRY this data anyways.
That being said, if you have the time and resources to maintain seed data it's absolutely a better way to go about it. It's also beneficial outside of tests.
> Generally I've seen a new database (schema in other dbs?) in postgres that is for testing, i.e "development_test" vs "development".
Every place I've ever worked which tried this has managed to get a production database deleted by somebody running tests.
if random users have creds to touch the prod database at all, much less delete data / drop tables, you had a big problem before you were running tests.
It also wouldn't fly in many regulated environments.
> It also wouldn't fly in many regulated environments.
Why not?
> Every place I've ever worked which tried this has managed to get a production database deleted by somebody running tests.
That's just a different way of saying "Every place I've ever worked at use production for testing" :-/
TBH, any place using the same credentials for test and for production have bigger problems than would ever be fixed by mocking.
You've made multiple assumptions here that couldn't be further from reality. You don't have to use production for testing or share test credentials between environments for automated tests to exploit an unintended environment, you just have to forget to clean up a `.env` file after testing a hotfix.
... is that good? Hell no. But it's a much more common version of reality than you're assuming is happening.
2 replies →
Do not delete develoment_test on your tests, it's supposed to be stable on your machine.
But, the one important thing is, do not give people direct access to production. And for the few that must have it, it should not be easy to connect to it.
If ANYBODY has quick and easy access to connect to the prod DB, let alone have prod DB creds, you are doing something very wrong.