Comment by lelanthran
13 days ago
> 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.
What you’re saying is tautological: your assumption is that tests were running in production, and your evidence is that somebody accidentally ran tests in production. It reads a bit like “Oh my, an accident? Why’ve you done that.”
Anyway, the missed point is that you can’t just do anything in tests and just expect the best of intentions to ensure it doesn’t backfire. One must also consider the security situation, infrastructure, secrets management, shared environments, and more. It’s not as simple as just plopping down a test database and expecting everything to go smoothly. You wouldn’t be that careless with other things, so don’t do it with tests, and don’t rely on “don’t run tests in production” as your only safeguard.