[mac01021]

We used a real database for testing. In the short term it was less work than architecting the application in a way that allowed the DB to be mocked.

Long term, the result was a 45-minute test suite which spent most of its time setting up records in the DB, and which could not be parallelized except by adding more instances of the real DB (otherwise the tests would interfere with one-another's assertions about the DB state).

[Rickasaurus]

but now with containers you can have a snapshot that's already set up in the right state. A separate build.

[theptip]

This is a powerful technique, though I'd say it's more useful for the build pipeline than for developers running UTs while coding (since the schema can change more frequently while doing so).

To provide a counterpoint though, an advantage touted by advocates of complete decoupling from the DB is that your UT suite can run in O(one minute), rather than O(ten minutes). E.g. see https://www.youtube.com/watch?v=tg5RFeSfBM4.

I'm not 100% sold on this approach yet (separating your domain objects entirely from the ORM wrapper is an uphill struggle), but it's interesting.

[Rickasaurus]

We run our tests on databases and it's on the order of one minute. Maybe it's a hardware issue? We all have beefy computers with fast SSDs.

Also since we strive to make our databases upgradable, it's important that the actual schema update scripts themselves are tested and used directly.