Comment by JasonSage
14 days ago
> 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.
> You've made multiple assumptions here that couldn't be further from reality.
Sure I've made an assumption, but in my defence it's a single reasonable assumption: that one wouldn't be running tests in production.
If you have a leftover `.env` that contains production credentials, you were running your test in production.
1 reply →
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.