Jul 16, 2021

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 Go’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.


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 Go 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.


// 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)


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.



About the Author

Scott Strzynski profile.

Scott Strzynski

Sr. Consultant

Scott is an experienced object oriented software developer with exposure to many industries. On several projects, has functioned as an architect, lead developer and technical mentor to inexperienced developers. He possesses both the business and technical background to be as autonomous or integrated as the situation requires.

One thought on “Creating Mocks For Unit Testing in Go

  1. Scott Strzynski says:

    One smart reader of the blog pointed out that the db var should be part of the messageReceiver struct. This is a good point; a little of my Java coding coming though in the definition

Leave a Reply to Scott Strzynski Cancel reply

Your email address will not be published.

Related Blog Posts
Natively Compiled Java on Google App Engine
Google App Engine is a platform-as-a-service product that is marketed as a way to get your applications into the cloud without necessarily knowing all of the infrastructure bits and pieces to do so. Google App […]
Building Better Data Visualization Experiences: Part 2 of 2
If you don't have a Ph.D. in data science, the raw data might be difficult to comprehend. This is where data visualization comes in.
Unleashing Feature Flags onto Kafka Consumers
Feature flags are a tool to strategically enable or disable functionality at runtime. They are often used to drive different user experiences but can also be useful in real-time data systems. In this post, we’ll […]
A security model for developers
Software security is more important than ever, but developing secure applications is more confusing than ever. TLS, mTLS, RBAC, SAML, OAUTH, OWASP, GDPR, SASL, RSA, JWT, cookie, attack vector, DDoS, firewall, VPN, security groups, exploit, […]