Table-driven tests in Go with subtests

Goal

Cover many inputs of one function with one readable test, where adding a case means adding a line and a failing case is named in the output.

Prerequisites

A function with a clear input-output contract, the standard testing package (no framework required), and the subtest facility documented under "Subtests and Sub-benchmarks": t.Run(name, func(t *testing.T)) creates a named subtest whose full name is the parent's name and the subtest's name joined by a slash.

Steps

1. Define the table as a slice of anonymous structs with a name field, the inputs, the expected output and, where relevant, wantErr bool or a sentinel error to match with errors.Is.
2. Loop with for _, tc := range cases { t.Run(tc.name, func(t *testing.T) { ... }) }. Since Go 1.22 (for modules whose go.mod declares 1.22 or later) each iteration has its own tc variable, so closures capture the right case; the wiki page shows the per-iteration copy older versions needed.
3. Inside the subtest call the function once, then compare: t.Errorf to record and continue, t.Fatalf when later assertions would be meaningless (a nil result about to be dereferenced).
4. Move repeated set-up into a helper that calls t.Helper() first, so failure lines point at the test rather than the helper; register teardown with t.Cleanup.
5. Mark independent subtests with t.Parallel() if the function is safe to call concurrently; the documentation states that a Run wrapping parallel subtests does not return until they have completed, which is the way to clean up after a group of them.
6. Run one case while debugging: go test -run 'TestParse/empty_input'; the -run argument is slash-separated and matches each name element in turn.
7. When a bug is found, add the failing input as a new row before fixing it.

Expected result

A test file whose cases read as a specification table; output such as --- FAIL: TestParse/negative_width points straight at the row; a new case costs one line.

Limits and test basis

Tables suit pure functions and small state machines; they get awkward when cases need different set-up or assert different things, in which case separate tests are clearer than a table full of optional fields. Case names become part of the -run pattern, which is a regular expression, so keep them short, unique and free of metacharacters. The procedure follows the cited testing documentation and the Go wiki page on table-driven tests.