VisaSpark
Sign in
intermediate18 min

Testing with go test

Writing a Go test file and reading `go test` output.

What you'll learn

  • Write a test function following Go's `TestXxx(t *testing.T)` naming convention
  • Use `t.Errorf` to report a failing assertion without stopping the whole test run
  • Read and interpret `go test` command-line output

Explanation

Go has testing support built directly into its standard toolchain -- no separate framework is required to get started. A test file is named something_test.go and lives alongside the code it tests. Each test is a function named TestXxx (must start with Test, followed by a capitalized word) taking one parameter, t *testing.T.

Inside a test, you check conditions yourself and report failures with t.Errorf(...) -- unlike some other languages' assert that stops execution immediately, t.Errorf records the failure and lets the rest of the test function keep running, so you can see multiple failures from one run instead of only the first.

You run tests with go test from the command line. A fully passing run prints something like PASS followed by ok package/path 0.002s; a failing test prints --- FAIL: TestName with your Errorf message, followed by an overall FAIL summary line.

Table-driven tests -- a slice of input/expected-output pairs looped over in one test function -- are the idiomatic Go way to test many cases without writing a separate function for each one, though that pattern is worth its own dedicated study once you're comfortable with a single basic test.

Guided lab

Predict: Reading go test output

GoNot executed
This lab does not run in your browser or on VisaSparkSchools's servers. Read the code, predict what it does, then reveal the real expected output.

Given this test file for a small `Add` function (with a deliberately wrong test case), predict what `go test` prints to the terminal.

// file: math.go
package mathutil

func Add(a, b int) int {
	return a + b
}

// file: math_test.go
package mathutil

import "testing"

func TestAdd(t *testing.T) {
	got := Add(2, 3)
	want := 6 // deliberately wrong -- 2 + 3 is actually 5
	if got != want {
		t.Errorf("Add(2, 3) = %d; want %d", got, want)
	}
}

Stuck? Get a hint.

Common mistakes

  • Naming a test function without the required `Test` prefix (or without capitalizing the word after it) -- `go test` silently won't run it.
  • Using `t.Fatalf` instead of `t.Errorf` when you actually want the rest of the test to keep checking other conditions after a failure.
  • Forgetting the test file must be named `..._test.go` -- `go test` only looks at files matching that suffix.

Knowledge check

Knowledge check

1. What must a Go test function's name start with?
2. What does `t.Errorf` do differently from stopping execution immediately?
3. What must a Go test file's filename end with for `go test` to find it?

Takeaway

Name test functions `TestXxx(t *testing.T)` in a `_test.go` file, and prefer `t.Errorf` over `t.Fatalf` so one run can surface every failure, not just the first.

Summary

Go's built-in testing package needs no separate framework: `_test.go` files, `TestXxx` functions, and `t.Errorf` for non-halting failure reporting, run via `go test`.

References

Your notes

Notes save automatically.

Finished this lesson?

Mark it complete to track your progress and schedule a future review.