Question

What I’ve done many times when testing database calls is setup a database, open a transaction and rollback it at the end. I’ve even used an in-memory sqlite db that I create and destroy around each test. And this works and is relatively quick.

My question is: Should I mock the database calls, should I use the technique above or should I use both – one for unit test, one for integration tests (which, to me at least, seems double work).

Answer 1

the problem is that if you use your technique of setting up a database, opening transactions and rolling back, your unit tests will rely on database service, connections, transactions, network and such. If you mock this out, there is no dependency to other pieces of code in your application and there are no external factors influencing your unit-test results.

The goal of a unit test is to test the smallest testable piece of code without involving other application logic. This cannot be achieved when using your technique IMO.

Making your code testable by abstracting your data layer, is a good practice. It will make your code more robust and easier to maintain. If you implement a repository pattern, mocking out your database calls is fairly easy.

Also unit-test and integration tests serve different needs. Unit tests are to prove that a piece of code is technically working, and to catch corner-cases.
Integration tests verify the interfaces between components against a software design. Unit-tests alone cannot verify the functionality of a piece of software.

HTH