Understanding Tests in Golang

All software development projects come with their fair share of bugs, and the time it takes to detect and correct them varies based on the project complexity and the nature of the error. Simple errors such as syntax errors are handled almost instantly with the help of code editors and increasingly helpful compilers.

Some issues, however, are more complicated than an absent semicolon. An important algorithm may have a logical flaw somewhere; edge cases may produce different results than what was intended; it may consume too much memory or be very slow for certain inputs. A code editor or compiler will most likely be of little help here.

Software testing

When dealing with less obvious errors, we test our programs and examine their output. While you can simply run your program and check the result manually, software testing usually refers to automated testing. In this case, you write some code to test the main code you wrote, generate relevant output, and give feedback.

Tests are sometimes seen as an unnecessary complexity in software projects, but it’s actually easy and fun to do in the right settings. My most preferred testing approach is from the Golang ecosystem.

Testing with Go

While other testing frameworks might feel like learning a entirely new programming language, Golang tests are basically Go code with some naming conventions. Below is a simple example of a Golang test:

Simple check for a “Summation” function

Go’s testing is low-tech, and can simply be written after mere minutes of becoming introduced to them. Beyond the naming conventions and the go test subcommand, there’s little new information to know on this topic.

the “go test” subcommand

The go test command is used to run tests. But before this, note that Golang only recognizes tests if they are written in a file with _test.go suffix in its name. The go test subcommand builds the program in a similar technique as go build, but it compiles files matching the pattern *_test.go and runs the tests specified in these files.

As you might have noticed from the example code, go test functions must start with a predetermined word. In the example, we used Test — this checks for accuracy and returns a PASS or a FAIL. We also have the Benchmark prefix — this reports the performance of an operation. It usually runs multiple times (b.N), and returns the average execution time.

Benchmarks tell you how much time your code took to run multiple times

Lastly, we have the Example test, which doesn’t return a value but serves as documentation or an example of how your code can be used and executed.

An Example test showing how a specific function can be used

Takeaways and further readings

• Go tests are simple, basic, and intuitive
• Test files should always end with a _test.go and test functions should start with Test, Benchmark, or Example, depending on the type of tests you’re writing
• If you want to check for accuracy, use the Test prefix; for speed performance, use Benchmark; for examples and/or documentation use Example.
• To run a test, run the subcommand go test on your terminal from the location of your software project files.
• The go test subcommand has different flags, some of which are:

to test a specific package: go test package_name

to show which tests are being executed (and time taken): go test -v

to run a specific test: go test -run=”Summation”

(you can pass the name of the test, or part of its name — it uses regular expression to match)

A comprehensive resource on tests is from Go’s official website: https://pkg.go.dev/testing

You can also find very helpful materials in books like The Go Programming Language (GOPL) by Donovan and Kernighan, and from helpful online materials like this.