Test execution modes

Canonical guidance

• use t.Parallel only for tests that are truly isolated
• run with shuffle sometimes to catch order dependence
• use -short and -run to control feedback loops deliberately

Use when

• large suites
• flaky ordering suspicions
• separating slow integration tests from fast unit tests

Avoid

• marking stateful tests parallel by default
• assuming deterministic test order matters
• making one CI mode do every job

Preferred pattern

func TestParse(t *testing.T) {
	t.Parallel()

	got, err := Parse("x=1")
	if err != nil {
		t.Fatal(err)
	}
	if got["x"] != "1" {
		t.Fatalf("x = %q", got["x"])
	}
}

Anti-pattern

• a suite that only passes because tests happen to run in a lucky order

Explanation: This anti-pattern is tempting because stable order hides shared-state bugs, but real test confidence comes from independence, not luck.

Why

• execution modes are cheap ways to surface hidden coupling