Patterns on gotest

Contract Testing Go Interfaces with Generic Test Suites

Tue, 21 Jul 2026 00:00:00 +0000

Go interfaces define contracts. An io.Reader promises Read(p []byte) (n int, err error). A Storage interface promises Get, Put, Delete. But who verifies that every implementation actually honors the contract? Usually, each implementation has its own tests, written independently, checking slightly different things. The contract drifts.

Generic suites fix this. Write one test suite parameterized by a type, then instantiate it for every implementation. The same behaviors are verified against every implementation. If you add a contract requirement, every implementation is tested. If an implementation deviates, the specific behavior that fails is named in the spec.

Snapshot Testing in Go

Fri, 17 Jul 2026 00:00:00 +0000

Some test assertions are about structure, not specific values. JSON API responses, rendered HTML, error messages, log output — things where the exact expected value is long, tedious to maintain by hand, and changes often enough to be annoying. Snapshot testing solves this by storing the expected output in a file and comparing against it on subsequent runs.

If you’ve used Jest, you know the pattern. In Go, it’s less common — but gotest has a built-in implementation that’s thread-safe, works inside parallel tests, and integrates with CI safety guards.

Testing Async Code in Go Without time.Sleep

Thu, 16 Jul 2026 00:00:00 +0000

Most Go code that tests async behavior uses time.Sleep. It’s slow, flaky, or both. The real problem is that sleeping conflates two separate concerns: how long to wait and how often to check. This post shows how to separate them with Eventually and Consistently, and why that separation makes async tests both faster and more reliable.

The sleep problem

Suppose you have a notification dispatcher that processes messages in a background goroutine. You send a notification and want to assert that it was delivered. The most common approach:

Go Test Lifecycle: Setup, Teardown, and Execution Order

Tue, 14 Jul 2026 00:00:00 +0000

Every test framework has setup and teardown. The interesting question is not whether they exist, but what guarantees the lifecycle gives you. Can AfterAll run if BeforeAll panics? Does AfterEach still execute on t.Fatal? Where do fixture hooks fit relative to suite hooks? If you have ever guessed at these answers while debugging a leaked database connection, this post is for you.

Other posts in this series cover fixture patterns and getting started with suites. This post is different. It maps the full lifecycle from the inside out, so you build the correct mental model once and stop guessing.

Test Fixtures in Go: Patterns That Scale

Tue, 07 Jul 2026 00:00:00 +0000

Most Go projects eventually need shared test infrastructure: a database connection, a message queue, a container that takes seconds to start. The stdlib doesn’t have a built-in answer for this. So every team invents its own fixture pattern, and most of those patterns quietly break the day you add t.Parallel() or a second package that needs the same Postgres.

This post looks at the common approaches, where each one breaks down, and what a fixture system needs to handle the cases that real projects run into.

Organizing Go Tests Beyond `func TestX`

Mon, 06 Jul 2026 00:00:00 +0000

A test file with 10 test functions is easy to hold in your head. At 50, you’re scrolling to find what you need. At 200, you’re grep-ing your own tests to figure out what’s covered and what isn’t.

Go’s testing package is deliberately simple. No annotations, no test classes, no dependency injection: just functions that start with Test and a *testing.T. This simplicity is one of Go’s genuine strengths. But it creates a gap that every growing project eventually falls into.