Creating Mocks For Unit Testing in Go

Unit testing is an important part of any project, and Go built its framework with a testing package; making unit testing part of the language.

This testing framework is good for most scenarios, but you need to put in a little extra effort to make it really work for your unit tests.  What do I mean with this? Simply put, most projects have packages that call other packages, and we want to isolate the testing to the unit of work. We do not want to worry about the implementation of dependent packages.

This is accomplished by taking advantage of GoLang’s compositional behavior.  Write your code as APIs with as many interfaces as possible.  This allows you to use any struct to handle behavior, as long as it implements the interface’s functions.

Mocks

In a complex application there will be times when code needs to interact with code outside the package. In order to isolate the testing to just the specific task, and not become an integration or e2e test, developers will need to rely on mocks. 

Look at this example, a user sends an http request, our package is responsible for applying business logic and then saving the message to a database.  It’s not reasonable to have a working DB for a unit test.

user http request -> business logic/validation  -> db.Upsert(document)

Think of a DynamoDB client library for database connectivity and persistence logic.  One may think it’s fine to call dynamo.UpdateItem() directly from the package that houses the business logic.  While that will work, it limits your ability to unit test.

A different approach is to create an interface to describe the DB API you wish to use.

// API
type DBLayer interface {
    Upsert(*Document) error
    Get(id string) (*Document, error)
}

This interface does two things:

• It decouples the business logic package from the actual database implementation package; if you decide to move to Mongo instead of Dynamo, your business logic package should not have to change.  
• This now allows all your test code in the business logic package to mock the database.

Writing mocks can become cumbersome, there can be a lot of inputs and expected outputs.  Your mocks and the expected results should also be separated, the mock should be implementation of the interface.  The expected results should be provided by the test.

Fortunately, there is a 3rd-party repo that will allow you to separate the mock interface definition and the expected test outputs.  Stretchr has a nice set of GoLang testing tools to help define mocks and write easy input output expectations.

Code Examples

In this example I will be mocking the DBLayer interface from above. This will be the API the business layer uses to interact with the DB.

func (ms *messageReceiver) ReceiveMessage(msg string) (int, error) {
    // database.Document is a generic struct I created to represent json
    doc := database.Document{ID: uuid.New().String(), Json: msg}

     // apply validation/business logic here ....

    err := db.Upsert(&doc)

The DB instance is passed into the MessageReceiver, I won’t cover all of that, the complete code can be found here. For this blog I will just focus on the mocking, so the next step is how to wire this up in a unit test.

DBMock

// Need a struct that will be used by the unit tests to contain the exported functions
type DBMock struct {
	mock.Mock  // Only need one field, Stretchr's Mock
}

Create implementation for all the functions from your interface (DBLayer) use the DBMock struct for the receiver func

func (m *DBMock) Upsert(doc *Document) error {
	// Called returns an array of interfaces that represents your func return values
	args := m.Called(doc)
	// You need to cast the interfaces in the array to their respective return type, Stretchr provides helpers for some.
    // Here since we have only one return arg and its an error
	return args.Error(0)
}

func (m *DBMock) Get(id string) (*Document, error) {

	args := m.Called(id)
	// In this case there are two return results expected.  Cast the first.
    // NOTE: If you are not using pointers for return values, trying to cast a nil to a non interface will result in a runtime error here trying to cast a nil to a struct
	return args.Get(0).(*Document), args.Error(1)
}

Tests

Now that the Mock has been defined, you can start creating expected results in your tests.

First, instantiate an instance of your mock struct

dbMock := &database.DBMock{}

Then specify behavior.

// On any value passed to Upsert return a nil error - successful upsert
dbMock.On("Upsert", mock.Anything).Return(nil)

// Only return errors on specific values passed in. 
// Calling Get with 123, return an error
dbMock.On("Get", “123”).Return(nil, errors.New(“cannot find doc”))

That’s it.  This is only scratching the surface of what mocks, and specifically Stretchr, can do.  Stretchr has an assert framework as well, that can be added to tests or mock definition.  I recommend viewing their examples on GitHub.

https://github.com/stretchr/testify

https://github.com/hal90210/go-mock