Subtests

Alright, let’s talk about testify. You’ve probably already felt the raw, existential pain of writing a test with the standard library’s testing package and thought, “There has to be a better way than if got != want { t.Errorf(...) } for the ten thousandth time.” You’re right. There is. Enter testify. This third-party library is practically part of the standard library at this point, given its ubiquity. It’s a toolkit that gives you three big weapons: assertions to make your test conditions readable, test suites to structure your tests, and mocks to, well, mock things. Let’s break it down.

Right, let’s talk about go test flags. This is where you stop just running tests and start interrogating them. The default go test is polite; it runs your tests and tells you if they passed. These flags are how you get it to spill its guts, confess its secrets, and do a little performance art for you. We’ll focus on the ones you’ll use daily. The -run Flag: Your Test Search Bar The -run flag is your first line of defense against running your entire 5,000-test suite when you just tweaked one function. It takes a regular expression and only runs tests whose names match it. Simple, right? The devil is in the details.

Right, let’s talk about making your benchmarks actually mean something. You’ve probably written a simple one, run it with go test -bench=., and stared at a number. But that number is a liar. It’s a filthy, opportunistic liar that will include all the setup time you did outside the loop, the time it took to generate your test data, and the cost of that one fmt.Printf you left in there “just for debugging.” We’re not here to be lied to. We’re here to get the truth, and for that, we have b.ResetTimer() and b.ReportAllocs().

Right, so you’ve written some code and it doesn’t explode. Congratulations. But is it fast? Or, more importantly, is it fast enough? And how do you know if your latest “optimization” actually made things better or just made the code look like a Rube Goldberg machine? You guess. I benchmark. In Go, benchmarking isn’t a dark art; it’s a first-class citizen built right into the testing package. A benchmark function looks almost identical to a test function, but it uses a different parameter: *testing.B instead of *testing.T.

Right, so you’ve written a helper function for your tests. It’s a beautiful, DRY little piece of logic that you’re rightfully proud of. You call it from three different test cases. Then you run go test and it fails. The output hits your terminal: --- FAIL: TestSomethingImportant (0.00s) my_test.go:47: Expected user to be active. You stare at the screen. Line 47? Which one of the three test cases called the helper? Which set of inputs caused this failure? You now have to play detective, tracing back through your test logic to figure out which specific scenario just blew up. This is annoying, and it violates a core principle of good testing: failures should be immediately obvious. This is where t.Helper() comes in—it’s the way you tell the testing framework, “Hey, when you report a failure, blame the function that called me, not me.”

Right, so you’ve written a table-driven test. It’s clean, it’s elegant, and you’re feeling pretty good about yourself. And you should. But now you run go test -v and you’re greeted with a monolithic block of output: TestMyFunction/input_1, TestMyFunction/input_2, … and when test #7 fails, you have to squint at the output to figure out which specific input scenario just blew up. And heaven forbid you want to run just that one failing scenario to debug it. You can’t. You have to run the whole table.

Right, let’s talk about table-driven tests. If you’re still writing tests by copying and pasting a test function and changing one or two values, I’m going to ask you politely, yet firmly, to stop. You’re not just creating more code to maintain; you’re missing out on one of the most elegant and powerful patterns in the Go testing ecosystem. The idea is brilliantly simple: you separate your test logic from your test data. Your test function becomes a single, clean engine, and your test cases become a slice of data that engine processes. It’s the difference between hand-crafting each meatball and having a perfectly calibrated meatball-making machine.

Right, so you’ve decided to write a test. Good for you. It’s the responsible thing to do, like flossing or not putting off that oil change. And in Go, the entry point for this particular brand of responsibility is a function named TestXxx, where Xxx is anything that doesn’t start with a lowercase letter. It’s not a suggestion; it’s how the go test command finds your work. You’ll be handed a *testing.T—think of it as your all-access pass to the test framework, your bullhorn for shouting about failures, and your notepad for logging what the heck is going on.