Mocking the DB in unit tests

[taobojlen]

I noticed that in some of our server unit tests (like these), we mock Kysely / the DB.

I'm curious about this. I generally find that on the backend, if you mock the primary database then a few issues arise:

• your tests become very tightly coupled to the implementation (i.e. to the specific queries being run)
• they become harder to read since so much of a test is setting up the right mocks
• your tests also become less trustworthy, because it's relatively easy to write flukes (i.e. tests that pass, but for the wrong reasons, like because your mocks are overly lenient in what they allow).

I'd suggest refactoring these tests so that they execute against an actual Postgres instance. It can make them a bit slower, but in general reliable tests > fast tests! (and I don't think we're near the point where test speed is a big concern). My PR #732 shows how we can also make this process smoother -- by running each test in a DB transaction that gets rolled back, you don't need to worry about each test cleaning up after itself, etc. because that's all handled automatically.

@juanmrad I'm curious to hear what you think of this!