What's the difference between stub and mock in Go unit testing? - unit-testing

Question

I am using mocks in unit testing in Go. How do I understand the difference between stub and mock in the implementation code in Go?

Answer 1

Intention of mocks and stubs in GO is the same as different programming languages:
stub is replacement for some dependency in your code that will be used during test execution. It is typically built for one particular test and unlikely can be reused for another because it has hardcoded expectations and assumptions.
mock takes stubs to next level. It adds means for configuration, so you can set up different expectations for different tests. That makes mocks more complicated, but reusable for different tests.
Let's check how that works on example:
In our case, we have http handler that internally makes http calls to another web service. To test handler we want to isolate handler code from dependency we do not control (external web service). We can do that by either using stub or mock.
Our handler code is the same for stub and mock. We should inject http.Client dependency to be be able to isolate it in unit test:
func New(client http.Client) http.Handler {
return &handler{
client: client,
}
}
type handler struct {
client http.Client
}
func (h handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
...
// work with external web service that cannot be executed in unit test
resp, err := h.client.Get("http://example.com")
...
}
Our replacement for run-time http.Client is straight-forward in stub:
func TestHandlerStub(t *testing.T) {
mux := http.NewServeMux()
mux.Handle("/", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
// here you can put assertions for request
// generate response
w.WriteHeader(http.StatusOK)
}))
server := httptest.NewServer(mux)
r, _ := http.NewRequest(http.MethodGet, "https://some.com", nil)
w := httptest.NewRecorder()
sut := New(server.Client())
sut.ServeHTTP(w, r)
//assert handler response
}
Mock story is more complicated. I am skipping code for mock implementation but this is how its interface may look like:
type Mock interface {
AddExpectation(path string, handler http.HandlerFunc)
Build() *http.Client
}
This is code for test using Mock:
func TestHandlerMock(t *testing.T) {
mock := NewMock()
mock.AddExpectation("/", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
// here you can put assertions for request
// generate response
w.WriteHeader(http.StatusOK)
}))
r, _ := http.NewRequest(http.MethodGet, "https://some.com", nil)
w := httptest.NewRecorder()
sut := New(mock.Build())
sut.ServeHTTP(w, r)
//assert handler response
}
For this simple sample it adds no much value. But think about more complicated cases. You can build much cleaner tests code and cover more cases with less lines.
This is how tests setup may look like if we have to call 2 services and evolved our mock a little bit:
mock.AddExpectation("/first", firstSuccesfullHandler).AddExpectation("/second", secondSuccesfullHandler)
mock.AddExpectation("/first", firstReturnErrorHandler).AddExpectation("/second", secondShouldNotBeCalled)
mock.AddExpectation("/first", firstReturnBusy).AddExpectation("/first", firstSuccesfullHandler)AddExpectation("/second", secondSuccesfullHandler)
You can imagine how many times you have to copy-paste handler logic in tests if we do not have our tiny mock helper. That copy-pasted code makes our tests fridgile.
But building your own mocks is not the only options. You can rely on existing mocking packages like DATA-DOG/go-sqlmock that mocks SQL.