Go
Table-driven tests are the dominant Go testing pattern for a reason: they separate test data from test logic, make adding cases trivial, and produce readable failure messages. The Go standard library uses them extensively. This guide covers the full pattern — from basic structs to parallel execution, error formatting, and
Go
Mocking in Go requires more boilerplate than in dynamic languages — you have to implement an interface manually or generate the implementation. The testify/mock package makes this manageable without reflection magic or code generation requirements. This guide covers the full workflow: defining mocks, setting expectations, asserting calls, and using mockery
Go
Unit tests with mocks verify your logic in isolation. Integration tests verify that your code actually works with real dependencies — the database, the cache, the message queue. testcontainers-go spins up real Docker containers during test execution and tears them down when done. No mocks. No test doubles. No "
Testing
testify/assert continues tests on failure; testify/require stops immediately. testify/suite groups tests with SetupTest/TearDownTest lifecycle hooks. testify/mock generates verifiable mock objects — call mock.AssertExpectations(t) at the end of every test. Combine suite + mock for organized integration-style tests. testify is the most widely used Go
Testing
Table-driven tests in Go group multiple test cases into a single slice of structs, then iterate with t.Run() for named subtests. Use t.Parallel() inside subtests for speed. Capture loop variables before goroutines. Break out of table-driven style when setup is too complex per case. Table-driven
Testing
Use httptest.NewRecorder() to test handlers directly in-process — fast, no TCP, no port. Use httptest.NewServer() when you need a real TCP server (e.g., testing an HTTP client). Both are in the standard library. Always call ts.Close() with defer. Use httptest.NewRequest() over http.NewRequest() for cleaner
Testing
Go 1.18+ has native fuzzing. Write FuzzXxx(f *testing.F) functions, add seed corpus with f.Add(), then run go test -fuzz=FuzzXxx. The fuzzer mutates inputs and reports panics or unexpected behavior. Reproduce failures with go test -run=FuzzXxx/testdata/fuzz/... after the crash file is saved. Fuzzing
Database Testing
PocketBase is an open-source backend in a single Go binary: embedded SQLite database, realtime subscriptions, file storage, auth, and an extensible Go framework — all in one 30MB executable. It's become popular for indie projects, prototypes, and small teams who want a real backend without the operational overhead.
Go
Go's race detector is a built-in tool that instruments your program to detect concurrent access to shared memory without synchronization.
HTMX
Go's net/http/httptest package makes testing HTMX endpoints straightforward — create a recorder, set the HX-Request header, call your handler, and assert on the HTML response. This works with any Go web framework: Gin, Chi, Echo, or stdlib http.ServeMux. Go's speed makes HTMX integration
Testing
NATS JetStream persistence introduces durable consumers, sequence-based message tracking, and stream retention policies. Testing these means verifying that a consumer resumes exactly where it left off after restart, that exactly-once deduplication works, and that your stream retention policy doesn't silently discard messages your consumers haven'
Database
Goose is the most widely-used database migration tool in the Go ecosystem, but its simplicity makes it easy to ship migrations without testing them. This guide covers a complete testing strategy using testcontainers-go, Go's standard testing package, up/down migration verification, and SQL assertion patterns that