New 42-day free trial
Smarty

Let's build an xUnit-style test runner for Go!

Michael Whatcott
Michael Whatcott
 | 
July 2, 2018
Tags
Smarty header pin graphic

Writing test functions in Go is easy:

package stuff

import "testing"

func TestStuff(t *testing.T) {
    t.Log("Hello, World!")
}

Running test functions is also easy:

$ go test -v
=== RUN   TestStuff
--- PASS: TestStuff (0.00s)
	stuff_test.go:6: Hello, World!
PASS
ok  	github.com/smartystreets/stuff	0.006s

Preparing shared state for multiple test functions is problematic. The usual recommendation is to use table-drive tests. But this approach has its limits. For us, xUnit is the ideal solution. It's simple, lightweight, and flexible. Wouldn't it be nice if we could define test methods on struct types and leverage common xUnit conventions like setups/teardowns, skipped tests, etc..? I'm thinking along these imaginary lines:

package stuff

import "testing"

// Define fields to manage system-under-test here (the fixture state).
type TestCase struct {
	*testing.T // Embedding *testing.T seems like a good idea for defining a test suite.
	sut *SystemUnderTest
}

// Perform setup actions here (instantiate test fixture state).
func (t *TestCase) Setup() {
	t.sut = NewSystemUnderTest()
}

func (t *TestCase) Test42() {
	if result := t.sut.Computation(42); result != 42 {
		t.Errorf("Got: [%d] Want: [%d]", result, 42)
	}
}

func (t *TestCase) Test43() {
	if result := t.sut.Computation(43); result != 43 {
		t.Errorf("Got: [%d] Want: [%d]", result, 43)
	}
}

The only problem is that the go test tool expects top-level functions, not methods on a struct type. And that's not going to change.

$ go test -v
testing: warning: no tests to run
PASS
ok  	github.com/smartystreets/stuff	0.006s

So, we need a way to connect a test function to methods on a struct type. And ideally, we could instantiate new instances of that type (with freshly initialized state) for each test method. Maybe a variation that leverages subtests would be closer to reality?

package stuff

import "testing"

func TestStuff(t *testing.T) {
	t.Run("Test42", new(TestCase).Test42)
	t.Run("Test43", new(TestCase).Test43)
}

// Define fields to manage system-under-test here (the fixture state).
type TestCase struct {
	sut *SystemUnderTest
}

// Perform setup actions here (instantiate test fixture state).
func (test *TestCase) Setup() {
	test.sut = NewSystemUnderTest()
}

func (test *TestCase) Test42(t *testing.T) {
    test.Setup()
	if result := test.sut.Computation(42); result != 42 {
		t.Errorf("Got: [%d] Want: [%d]", result, 42)
	}
}

func (test *TestCase) Test43(t *testing.T) {
    test.Setup()
	if result := test.sut.Computation(43); result != 43 {
		t.Errorf("Got: [%d] Want: [%d]", result, 43)
	}
}

That was certainly more effective:

$ go test -v
=== RUN   TestStuff
=== RUN   TestStuff/Test42
=== RUN   TestStuff/Test43
--- PASS: TestStuff (0.00s)
    --- PASS: TestStuff/Test42 (0.00s)
    --- PASS: TestStuff/Test43 (0.00s)
PASS
ok  	github.com/smartystreets/stuff	0.006s

But there are problems with this approach. Every time we define a new test method on the TestCase type we have to remember to register a subtest in the top-level test function. Oh, and did you notice how each test was calling the Setup method directly? This is something that should happen automatically if we're going to call this an xUnit-style test runner. It would be great if we could just call a method that points to our TestCase and iterates all test methods, calling Setup followed by a call to the test method.

From the calling side it could look something like this:

func TestStuff(t *testing.T) {
    xunit.RunTests(new(TestCase), t)
}

Notice we have to provide the *testing.T and an instance of our TestCase. The behavior defined in the mysterious xunit package would then find all the tests and run them. Impossible, you say? Not so! In fact, a draft implementation is trivial!

package xunit

import (
	"reflect"
	"strings"
	"testing"
)

func RunTests(fixture interface{}, t *testing.T) {
	fixtureType := reflect.TypeOf(fixture)

	for x := 0; x < fixtureType.NumMethod(); x++ {
		testMethodName := fixtureType.Method(x).Name
		if strings.HasPrefix(testMethodName, "Test") {
			// IMPORTANT: each test gets a new instance!
			instance := reflect.New(fixtureType.Elem())

			setupMethod := instance.MethodByName("Setup")
			callableSetup := setupMethod.Interface().(func())
			callableSetup()

			testMethod := instance.MethodByName(testMethodName)
			callableTest := testMethod.Interface().(func(t *testing.T))
			t.Run(testMethodName, callableTest)
		}
	}
}

This implementation makes a LOT of assumptions, lacks several features (like 'teardowns' and skipped tests) and isn't very robust, but hopefully you can see the emergence of an xUnit-style test runner. Most importantly, the tests are passing again:

$ go test -v
=== RUN   TestStuff
=== RUN   TestStuff/Test42
=== RUN   TestStuff/Test43
--- PASS: TestStuff (0.00s)
    --- PASS: TestStuff/Test42 (0.00s)
    --- PASS: TestStuff/Test43 (0.00s)
PASS
ok  	github.com/smartystreets/stuff	0.006s

Congratulations, you now possess a basic understanding of the inner workings of gunit! Stay tuned for a future post featuring a more in-depth look into xUnit-style testing in Go with gunit. In the meantime, feel free to kick the tires and fix things up a bit.


Source Code Download

Subscribe to our blog!
Learn more about RSS feeds here.
rss feed icon
Subscribe Now
Read our recent posts
Improving user/customer experience in every industry with clean address data
Arrow Icon
You finally track down an essential addition to your collector’s set of [insert item of your choice], and you're hyped to buy it until the chaos begins. The cart is hidden in a fly-out on the side, cluttered with blocky, overwhelming text. You spend way too long just trying to find the "Proceed to Checkout" button. 👎 That’s bad UI (user interface): messy, confusing design that makes navigation a chore. You make it to the checkout and start entering your info, but the site keeps rejecting your address.
Dashboard essentials for Smarty users
Arrow Icon
The Smarty dashboard is your central hub for managing address verification, geocoding, and property data services. Whether you're just starting or looking to optimize your current setup, understanding the dashboard's full capabilities can significantly streamline your address data operations. We recently held a webinar in which we reviewed all of the Smarty dashboard's items and features. Missed it? That's OK; we've got all the information right here. You can expect to read about:Accessing your dashboardSetting up your account for successUnderstanding your active subscriptionsManaging API keys effectivelyStreamlining billing and financial managementStaying informed with smart notificationsTeam management and access controlsWeb toolsMaking the most of free trialsKey takeawaysLet’s get going!Accessing your dashboardGetting to your dashboard is straightforward.
Take charge of your API usage with Smarty’s key management features
Arrow Icon
Ever wondered, “Where did all my lookups go?!” Without proper API management, you may burn through your lookups quicker, experience runaway code, and encounter unexpected usage. That’s why Smarty created usage by key (included in all annual plans) and limit by key (included in some plans; you can add them by contacting sales) for its APIs. Why key management mattersCommon API usage challenges (problems to solve):Unexpected spikes in lookupsDifficulty tracking specific key usageWhich keys are calling which Smarty licenseNeed for better control over API consumptionDifficulty allocating Smarty lookups across an organizationWith Smarty's key management features, you gain more control by having better visibility of your usage, eliminating the element of surprise (you know, the bad kind, like when you’re suddenly out of lookups).

Ready to get started?