4 ms·

But do you really need to mock the database when you can just deploy a containerized one for testing?

• mac01021 9y ago
  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 9y ago
    but now with containers you can have a snapshot that's already set up in the right state. A separate build.
    • theptip 9y ago
      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 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 9y ago
        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.