[JasonSage]

> 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.

[bananapub]

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.

[MajimasEyepatch]

It also wouldn't fly in many regulated environments.

[lelanthran]

> It also wouldn't fly in many regulated environments.

Why not?

[lelanthran]

> 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.

[JasonSage]

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.

[lelanthran]

> 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.

[JasonSage]

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.

[marcosdumay]

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.

[Sohcahtoa82]

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.