A service that calls another service can be hard to test reliably: the dependency may be unavailable, return an unexpected value, or receive the wrong input. A mock stands in for that dependency. Like a stub, it supplies controlled results; unlike a simple stub, it can also verify which methods were called and with what arguments. section 6.5 section 6.4
Put an interface between the code under test and its dependency, then inject a mock implementation. For a remote translation service, the HelloClient interface exposes Translate(word, language), allowing tests to replace the external client without testing the external service itself. section 6.5
A practical test sequence is:
- Create a fresh mock and service for each test. A Testify suite can use SetupTest for this shared setup. section 6.5.1
- Set an expected call and its return values with On(...).Return(...), run the service, check the result, and call AssertExpectations. section 6.5.2
- Vary the expectations to exercise input normalization, errors, and repeated calls. An expectation of one client call can test whether a cache serves the second request. section 6.5.2
Catch a wrong argument
Expect Translate("foo", "bar") to return "baz", then call the service with "Foo". The mock reports that the expected call did not occur. Lowercasing the input before the client call makes the expectation pass. A separate test can return an error from the mock and verify that the service returns an empty string. section 6.5.2
Listing 6.14 remote_translator_test.go
package translation_test
...
func (suite *RemoteServiceTestSuite) TestTranslate() {
// Arrange
suite.client.On("Translate", "foo", "bar").Return("baz", nil) #1
// Act
res := suite.underTest.Translate("foo", "bar")
// Assert
suite.Equal(res, "baz") #2
suite.client.AssertExpectations(suite.T()) #3
}
A compact Go example of arranging a client response, calling the service, and asserting both the result and the expected interaction. section 6.5.2
Use mocks when the interaction matters, not as a replacement for sound design. They require more setup than stubs; if a service needs a tangle of mocks, consider whether the service or its dependencies should be simplified. section 6.7 section 6.8
