> but for API calls and databases, just have the test write to the prod environment, but include rollback/cleanup in the test I disagree with that. Automated t

> but for API calls and databases, just have the test write to the prod environment, but include rollback/cleanup in the test I disagree with that. Automated testing should be done on a test database. Holding a lock for too long could effectively block the entire production. This could happen while debugging through a test (e.g. by hitting a breakpoint or by just stepping line-by-line). Or by simply having a bug in the test causing a "transaction leak" - depending on the tech stack, this could keep the transaction and the associated locks alive until all tests have finished running, not just the one which had the bug. Or you could commit instead of rollback by mistake. Or you could simply put unexpected strain on the database, affecting the performance of real users.