Welcome fellow coders! In this tutorial, we are going to be taking a look at selection of more advanced testing practices used by the likes of the Go core language developers and in popular production-level tools.
I feel this approach, of actually studying what has been done in a production system, will hopefully give you some insight into the best ways to test your own production-level Go programs.
Note - If you are entirely new to testing your Go-based programs, then I suggest you check out my other tutorial: an introduction to testing in go
Achieving Good Coverage with Table Driven Tests
Let’s start our journey in the
strings package. If you have a look at the top of the
strings_test.go file within
src/strings/ you should see a number of arrays defined and populated.
For example, take a look at
lastIndexTests which is an array of type
This array is used to test the
LastIndex function within the
strings.go file with a number of negative and positive cases. Each of these
IndexTest elements feature a standard
string, a separator, and an
out integer value and have a
struct that looks like this:
These tests are then triggered by the
TestLastIndex() function which runs through all of these test cases and checks to see whether the results returned from the
lastIndex function match the expected results outlined in the array.
This same practice is done numerous times for numerous different functions and this helps to guarantee that when any code changes are made to these functions, the expected functionality will not change.
Use the testdata Directory
In certain situations, you won’t be able to specify your expected input and output as an array of elements like in the above example. You may be trying to test how you read + write to files on the filesystem or how you parse proprietary data formats and so on.
If this is the case then one option is to create a
testdata directory and store any files you may need for testing within that directory.
A great example of this can again be found within the Standard Library under
src/archive/tar/ in which a
testdata/ directory is defined and contains a number of
.tar files that are subsequently used for testing.
Some fairly complex examples of tests using these files can be found in the
In the above function you’ll see that the core developers are combining the first technique we covered here in combination with files from the
testdata/ directory to ensure that when a sample
.tar file is opened, the files and their checksums match their expectations.
Mocking HTTP Requests
As soon as you start writing production-level APIs and services, it’s likely you’ll start interacting with other services and being able to test the way that you interact with these services is just as important as testing other parts of your codebase.
However, you may be interacting with REST APIs that perform CRUD actions on databases and as such, you don’t want these changes actually being committed to your database when you are just trying to test things are working.
So, in order to get around this problem, we can mock HTTP responses using the
net/http/httptest package which is our best friend in these situations.
In the above test case, we basically overwrite the response we expect from our URL and then continue to test other parts of our system that rely upon that response.
The Use of Separate Packages
If we have a look at the
strings_test.go file and inspect the package at the top, you should notice that it doesn’t reside within the same package that the
strings.go file resides within.
The reason for this? It helps you to avoid cyclic imports. In some scenarios, you’ll need to import a package in your
*_test.go file to adequately write your tests. If the package you import in already has a reference to the package you are trying to test, you may see issues with cyclic dependencies.
Differentiate your Unit and Integration Tests
Note - I originally found out about this tip from: Go Advanced Tips Tricks
If you are writing tests for large enterprise Go systems then you’ll more than likely have a set of both
unit tests ensuring the validity of your system.
More often than not however, you’ll find your integration tests taking far longer to run as opposed to your unit tests due to the fact they could be reaching out to other systems.
In this case, it makes sense to put your integration tests into
*_integration_test.go files and adding
// +build integration to the top of your test file:
In order to run this suite of integration tests you can call
go test like so:
So, in this tutorial, we had a look at some of the more advanced testing techniques and tricks employed by the Go language maintainers.
Hopefully, you found this useful and it gave you the insight needed to go off and improve your own go tests. If you found it useful, or have any further questions, then please don’t hesitate to let me know in the comments section below!
Note - If you want to keep track of when new Go articles are posted to the site, then please feel free to follow me on twitter for all the latest news: @Elliot_F.
If you enjoyed this, you may like my other articles on testing in Go: