Source: qvault.io
Writing Good Unit Tests; Don’t Mock Database ConnectionsCategory: Database
More importantly, unit tests allow us to make updates to our code base with the confidence that we haven’t broken anything. In our eagerness to get 100% code coverage, however, we often write tests for logic that perhaps we have no business testing.
In Go, unit tests can be executed using the go test command and some example source code looks something like this: Where we are testing the logPow function that looks like this: The goal of unit tests is to test a “unit”, or small portion, of code.
The only test we probably need here is to test our own business logic, the validateUser function.
I believe that the majority of database and API mocking is a result of bad code, and that to fix the problem, the best course of action is to refactor into smaller functions or “units” as we did a moment ago.
In Go, unit tests can be executed using the go test command and some example source code looks something like this: Where we are testing the logPow function that looks like this: The goal of unit tests is to test a “unit”, or small portion, of code.
The only test we probably need here is to test our own business logic, the validateUser function.
I believe that the majority of database and API mocking is a result of bad code, and that to fix the problem, the best course of action is to refactor into smaller functions or “units” as we did a moment ago.
Related Articles
Community Partners
DevOps Careers