A practical guide on adopting `t.Parallel()` in Go test suites to speed up large packages. Using it on a ~200-test API package reduced single-run time by 30-40% and 10-run time by 2-3x. The post covers the rationale, concrete benchmarks, and the real-world problems encountered: database deadlocks from concurrent upserts (solved with pre-seeded fixtures and transaction rollbacks), interleaved log output (solved with `t.Logf` adapters), goroutine leak detection conflicts with goleak (solved via `TestMain`), and subtest parallelism trade-offs (solved with a custom `ignore-missing-subtests` linter option). The author also contributed an `ignoremissingsubtests` option to the `paralleltest` linter to support partial adoption.

10m read timeFrom brandur.org
Post cover image
Table of contents
Is `t.Parallel()` broadly recommended practice?Sharp edgesOther notesTakeaways
3 Impressions