The Adapter Pattern in Go

Honestly, just use a real db in testing. Purity is all well and good, but not at the expense of more bugs caught.

The problem with this approach in practice is that the abstraction tends to leak real fast. One day you'll need to hack something ugly to fix a performance issue in prod or whatever and it all will come crashing down.

If you want to mock a database to have a fast subset of tests, first test the client the hard way and prove you’re using the real database correctly (not just asserting what you hope it would do).

Any ideas how you test the SQL using this approach?

Besides mocks hiding subtle bugs, the adapter approach can very easily hide costs. This is how you end up with O(n) SQL queries.