Testing in Go — the built-in testing package and table-driven tests

Unlike many languages where picking a testing framework is an early decision, Go's standard library includes a complete one: the testing package, paired with the go test command. A test file sits right next to the code it tests, ending in _test.go:

A test function must start with Test, take *testing.T, and report a failure by calling a method on t (like t.Errorf) — a test that never calls a failure method automatically passes, since Go's testing model doesn't require you to explicitly assert success.

Testing several inputs against the same function usually means writing the same test logic repeatedly with different values — Go's community convention instead collects the cases as data and loops over them once:

t.Run registers each case as its own named subtest — if one row fails, go test reports exactly which named case failed, and every other row still runs to completion instead of the whole function stopping at the first failure. Adding a new test case becomes adding one line to the table, not writing a new function.

Table-driven tests are close to the default way experienced Go developers test anything with more than one meaningful input case — recognizing the pattern (a struct slice, a loop, t.Run) on sight is essential to reading real Go test files, and reaching for it yourself is what keeps a growing list of edge cases from turning into a growing list of nearly-identical, copy-pasted test functions.