Isolating and mocking the database in Go tests
We write code all the time and managing tight coupling is a challenge we actvely face. This post attempts to address and show a practical example of seperating our concerns(business logic) and the database. While this post describes this process via a database, note that it can be applied to any other part of the codebase.
PS, mocking 101,
Coming from other languages, a lot of people usually want an ORM or some library that does a lot of heavy lifting. Everyone then says “That isn’t the go way”, then you decide to go pure sql only and the entire codebase gets tied to the database…
To fix this issues, we have to separate our API from the nice abstraction
database/sql gives us.
So assuming, we are building a blog. We can create, delete and view posts. Obviously, we have to make use of some database to store this data. I would only go through the main concepts here, if anyone is interested in seeing what the entire code looks like, Github is the place to be.
To properly define boundaries for our code and make it replaceable at will, we have to make use of an interface. With that in place we can write as many as possible implementations of that (mongodb, mysql or boltdb and not forgetting a dummy implementation)… This applies to any other stuff that has to deal with external services - mail service, external queue system..
Here, we have declared
app.DB to be of type
store, so we can easily switch between mysql and something else with a config file -probably . To use sqlite3, we would have something like :
Then in our handlers, we would access
While we have a functional connection to sqlite3, remember we still don’t want to touch the database in the test suite..
The most interesting here is
fakeStore. It is a mock that has expectations and stubs (return values) so as to make itself seem real. While it can be written by hand, I made use of a tool called mockery that autogenerates structs based on interfaces.
While this is good enough, we might have a problem. And that is as a result of mocking (suprised ?), we could run into problems where the ci build passes but the code fails in production because we wrote poorly formatted sql. To fix this issue, I have found sqlmock useful.
Another thing is it starts to get complex, so for small projects, I mock all through but for any other thing, I would rather just make use of an in memory sqlite database while keeping MYSQL for production.