How To Create Testable Go Code
Table of Contents
Testing your code is a good idea, but sometimes you might be testing the wrong thing, or even worse, testing nothing. Sometimes it might not be clear how to test something, or you might think something is not testable at all. This article is here to show you some tricks on making your code more testable, and a thought process you can apply to testing your code.
Before we start let’s get one thing out of the way: You don’t need a third party testing framework. We have all the tools we need right here in the Go standard lib, and this guide will be using those tools exclusively. You certainly don’t need to import an entire “assert” library to avoid writing one if statement. See: https://golang.org/doc/faq#testing_framework if you disagree with me.
Let’s start with a simple example of a test. Here is a function that finds the average of a slice of floats:
func average(values []float64) float64 {
var total float64 = 0
for _, value := range values {
total += value
}
return total / float64(len(values))
}
This is a perfectly testable function. We know what the output should be given any input, so we can test it very easily:
func Test_Average(t *testing.T) {
result := average([]float64{3.5, 2.5, 9.0})
if result != 5 {
t.Errorf("for test average, got result %f but expected 5", result)
}
}
This is a valid, and useful, test. But it only tests one option. Testing multiple inputs can get messy, unless you organise well. It is ideal to create an array of test cases:
func Test_Average(t *testing.T) {
tests := []struct{
name string
input float64
expectedResult float64
}{
{
name: "three normal values",
input: []float64{3.5, 2.5, 9.0},
expectedResult: 5,
},
{
name: "handle zeroes",
input: []float64{0, 0},
expectedResult: 0,
},
{
name: "handle one value",
input: []float64{15.3},
expectedResult: 15.3,
},
}
for _, test := range tests {
result := average(test.input)
if result != test.expectedResult {
t.Errorf(
"for average test '%s', got result %f but expected %f",
test.name,
result,
test.expectedResult,
)
}
}
}
So we can now handle many test cases elegantly. Unfortunately not all code is going to be as simple as this. Let’s consider if the function was like this:
func averageFromWeb() (float64, error) {
resp, err := http.DefaultClient.Get("http://our-api.com/numbers")
if err != nil {
return 0, err
}
values := []float64{}
if err := json.NewDecoder(resp.Body).Decode(&values); err != nil {
return 0, err
}
var total float64 = 0
for _, value := range values {
total += value
}
return total / float64(len(values)), nil
}
Now our code is hitting an API to get the values. We could still run the same test on this code, but we would be relying on that API to provide us with the same values every single time. We would also be limited to just a single test case, even if we could rely on the API in that way. Not to mention it’s not ideal to be relying on a connection to our API, or to hit our API every time we test. Let’s avoid racking up unnecessary cloud bills, shall we?
It’s at this point that we need to ask ourselves, what is it that we are actually trying to test here? Are we trying to test that the Golang HTTP library can make HTTP calls? No. We didn’t write that code. We want to test all of the other code around it that we wrote. That is, calculating the average of the values.
So how do we call this function in a test, but also avoid testing the HTTP call? We need to mock it. But before we can do that, we need to make it mockable. This will require some tricky setup. The first thing we do is turn the HTTP part of the function into a seperate function:
func getValues() (float64, error) {
resp, err := http.DefaultClient.Get("http://our-api.com/numbers")
if err != nil {
return nil, err
}
values := []float64{}
if err := json.NewDecoder(resp.Body).Decode(&values); err != nil {
return nil, err
}
return values, nil
}
Now our original function could use this function. But that doesn’t make the code mockable just yet. The HTTP call still happens. We need to have a mock version of this function that doesn’t call the API, but just returns some values we choose:
function getValues() (float64, error) {
return []float64{1.0, 2.5}, nil
}
The issue with this is, when we run this code for real, we want the real version to run. We want the HTTP call to happen. But when we test it, we want the mock version of the function to run. We need to be able to run this function with two different setups. A real setup, and a mock setup.
This is where an interface comes in handy. The averageFromWeb function doesn’t need to know what version of the getValues function is running, it just needs to know the output types. So let’s make that an interface:
type ValueGetter interface {
GetValues() ([]float64, error)
}
Now, we could set up our function so that we pass in the implementation of this interface, like so:
func averageFromWeb(valueGetter ValueGetter) (float64, error) {
values, err := valueGetter.GetValues()
if err != nil {
return 0, err
}
var total float64 = 0
for _, value := range values {
total += value
}
return total / float64(len(values)), nil
}
This works for this scenario, but it’s not going to scale for us in the future. Say we had 20 functions that all call different HTTP services, or databases, etc. We don’t want to have to pass the implementations for all of those services and database around everywhere we go. We will have spaghetti code in no time. To make this elegant, we can create a “service” struct that can hold our implementation details, and make our function a method on that struct:
type service struct {
valueGetter ValueGetter
}
func (s service) averageFromWeb() (float64, error) {
values, err := s.valueGetter.GetValues()
if err != nil {
return 0, err
}
var total float64 = 0
for _, value := range values {
total += value
}
return total / float64(len(values)), nil
}
Now we’re talking. The last two things we need are our implementations of ValueGetter. Here they are:
// The real implementation //
type httpValueGetter struct {}
func (h httpValueGetter) GetValues() (float64, error) {
resp, err := http.DefaultClient.Get("http://our-api.com/numbers")
if err != nil {
return 0, err
}
values := []float64{}
if err := json.NewDecoder(resp.Body).Decode(&values); err != nil {
return 0, err
}
return values, nil
}
// The mock implementation //
type mockValueGetter struct {
values []float64
err error
}
func (m mockValueGetter) GetValues() (float64, error) {
return m.values, m.err
}
Now we have a nicely mockable, and scalable service model for our function. In the real version of our code we’ll initialise this service with the real version of the ValueGetter like so:
func main() {
service := service{valueGetter: httpValueGetter{}}
average, err := service.averageFromWeb()
if err != nil {
panic(err)
}
fmt.Println(average)
}
And our test will look like this:
func Test_Average(t *testing.T) {
testError := fmt.Errorf("an example error to compare against")
tests := []struct{
name string
input []float64
err error
expectedResult float64
expectedErr error
}{
{
name: "three normal values",
input: []float64{3.5, 2.5, 9.0},
expectedResult: 5,
},
{
name: "handle zeroes",
input: []float64{0, 0},
expectedResult: 0,
},
{
name: "handle one value",
input: []float64{15.3},
expectedResult: 15.3,
},
{
name: "error case",
input: []float64{3.5, 2.5, 9.0},
err: testError,
expectedErr: testError,
},
}
for _, test := range tests {
service := service{valueGetter: mockValueGetter{
values: test.input,
err: test.err,
}}
result, err := service.averageFromWeb()
if err != test.expectedErr {
t.Errorf(
"for average test '%s', got error %v but expected %v",
test.name,
err,
test.expectedErr,
)
}
if result != test.expectedResult {
t.Errorf(
"for average test '%s', got result %f but expected %f",
test.name,
result,
test.expectedResult,
)
}
}
}
Fantastic! We’re creating the mockValueGetter using the same input values from the test we made earlier, and also testing the error case.
This approach can be used to easily mock out any part of the code, including HTTP calls, database queries, and more. There is also an added advantage of making the code more modular and maintainable. Try this out on your own codebase and see how much more of your code you can test!