{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreidlmhtskko7p4pmb4nxw36o5o4gxh67sjvm4tzmazijcwtoujmu4u",
"uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3moxd4gruyj22"
},
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreibxkl7nhjarzbitx4qww6zc24phq3htgs4vojs3cnuu32bqzoj5jy"
},
"mimeType": "image/webp",
"size": 99612
},
"path": "/mihirmohapatra/testing-in-go-table-driven-tests-benchmarks-and-go-test-habits-gmc",
"publishedAt": "2026-06-23T11:27:55.000Z",
"site": "https://dev.to",
"tags": [
"go",
"testing",
"backend",
"part 5",
"@ParameterizedTest"
],
"textContent": "## Testing in Go — Table-Driven Tests, Benchmarks, and go test Habits\n\nIn part 5 I built a working Orders API with Gin — routes, middleware, an in-memory store, and proper error handling. This time I'm writing tests for it, and the story here is one of the things I've genuinely liked about Go from the start: testing is a first-class citizen with zero framework ceremony. No JUnit, no Mockito, no Spring Boot test context to spin up. Just `go test` and the standard library.\n\n### The go test Mental Model\n\nEvery `_test.go` file in a Go package is compiled and run by `go test`. Test functions follow one convention — they take a single `*testing.T` argument and start with `Test`:\n\n\n\n func TestSomething(t *testing.T) {\n // ...\n }\n\n\nThat's the entire contract. No annotations, no base classes, no test runner configuration file. Running `go test ./...` from the project root picks up every test across every package recursively. Running with `-v` shows each test name and its pass/fail. Running with `-race` enables the data race detector we talked about in part 3. These three invocations cover 90% of what I reach for day to day:\n\n\n\n go test ./... # run everything\n go test -v ./handler/... # verbose, one package\n go test -race ./... # race detector on\n go test -run TestCreateOrder . # run one test by name\n\n\n### Table-Driven Tests: The Go Idiom\n\nThe single most important testing pattern in Go is the table-driven test. Instead of writing one test function per scenario, you define a slice of cases as a struct, loop over them, and let the test framework tell you exactly which case failed. Coming from JUnit's `@ParameterizedTest`, it's the same idea — except it's just a `for` loop, no framework required:\n\n\n\n // store/order_test.go\n package store_test\n\n import (\n \"testing\"\n\n \"orders-api/model\"\n \"orders-api/store\"\n )\n\n func TestCreateOrder(t *testing.T) {\n cases := []struct {\n name string\n input model.CreateOrderRequest\n wantErr bool\n }{\n {\n name: \"valid order\",\n input: model.CreateOrderRequest{Customer: \"Alice\", Amount: 99.99},\n wantErr: false,\n },\n {\n name: \"zero amount\",\n input: model.CreateOrderRequest{Customer: \"Bob\", Amount: 0},\n wantErr: false, // store doesn't validate, handler does\n },\n {\n name: \"empty customer\",\n input: model.CreateOrderRequest{Customer: \"\", Amount: 50.0},\n wantErr: false,\n },\n }\n\n for _, tc := range cases {\n t.Run(tc.name, func(t *testing.T) {\n s := store.NewInMemoryStore()\n order, err := s.Create(tc.input)\n\n if tc.wantErr && err == nil {\n t.Errorf(\"expected error, got nil\")\n }\n if !tc.wantErr && err != nil {\n t.Errorf(\"unexpected error: %v\", err)\n }\n if !tc.wantErr && order.ID == \"\" {\n t.Errorf(\"expected non-empty order ID, got empty string\")\n }\n })\n }\n }\n\n\n`t.Run` creates a named sub-test for each case. When a sub-test fails, Go prints the full path — `TestCreateOrder/zero_amount` — so you know instantly which case broke without digging through output. This is the pattern the entire Go standard library uses internally, and it's the first habit worth locking in.\n\n### Testing the Store: ErrNotFound\n\nThe `GetByID` path needs its own table — specifically the not-found branch we wired into the handler in part 5:\n\n\n\n func TestGetByID(t *testing.T) {\n s := store.NewInMemoryStore()\n\n // seed one order\n created, _ := s.Create(model.CreateOrderRequest{\n Customer: \"Alice\",\n Amount: 49.99,\n })\n\n cases := []struct {\n name string\n id string\n wantErr error\n }{\n {\"existing order\", created.ID, nil},\n {\"missing order\", \"does-not-exist\", store.ErrNotFound},\n {\"empty id\", \"\", store.ErrNotFound},\n }\n\n for _, tc := range cases {\n t.Run(tc.name, func(t *testing.T) {\n _, err := s.GetByID(tc.id)\n if !errors.Is(err, tc.wantErr) {\n t.Errorf(\"got err %v, want %v\", err, tc.wantErr)\n }\n })\n }\n }\n\n\n`errors.Is` in the test assertion mirrors exactly how the handler checks errors — the sentinel defined in the store package is the contract, and we're verifying both sides of it honour it.\n\n### Handler Tests with httptest\n\nTesting the handler layer without spinning up a real server is where Go's `net/http/httptest` package earns its place. It gives you a fake `ResponseRecorder` that captures everything the handler writes — status code, headers, body — without any network involvement:\n\n\n\n // handler/order_test.go\n package handler_test\n\n import (\n \"bytes\"\n \"encoding/json\"\n \"net/http\"\n \"net/http/httptest\"\n \"testing\"\n\n \"orders-api/handler\"\n \"orders-api/model\"\n \"orders-api/store\"\n\n \"github.com/gin-gonic/gin\"\n )\n\n func setupRouter(h *handler.OrderHandler) *gin.Engine {\n gin.SetMode(gin.TestMode)\n r := gin.New()\n r.POST(\"/orders\", h.Create)\n r.GET(\"/orders/:id\", h.GetByID)\n r.GET(\"/orders\", h.List)\n return r\n }\n\n func TestCreateOrderHandler(t *testing.T) {\n cases := []struct {\n name string\n body any\n wantStatus int\n }{\n {\n name: \"valid request\",\n body: model.CreateOrderRequest{Customer: \"Alice\", Amount: 99.99},\n wantStatus: http.StatusCreated,\n },\n {\n name: \"missing customer\",\n body: map[string]any{\"amount\": 49.99},\n wantStatus: http.StatusBadRequest,\n },\n {\n name: \"negative amount\",\n body: map[string]any{\"customer\": \"Bob\", \"amount\": -10},\n wantStatus: http.StatusBadRequest,\n },\n }\n\n for _, tc := range cases {\n t.Run(tc.name, func(t *testing.T) {\n s := store.NewInMemoryStore()\n h := handler.NewOrderHandler(s)\n r := setupRouter(h)\n\n bodyBytes, _ := json.Marshal(tc.body)\n req := httptest.NewRequest(http.MethodPost, \"/orders\", bytes.NewReader(bodyBytes))\n req.Header.Set(\"Content-Type\", \"application/json\")\n w := httptest.NewRecorder()\n\n r.ServeHTTP(w, req)\n\n if w.Code != tc.wantStatus {\n t.Errorf(\"status: got %d, want %d — body: %s\",\n w.Code, tc.wantStatus, w.Body.String())\n }\n })\n }\n }\n\n\n`gin.SetMode(gin.TestMode)` suppresses the debug output Gin prints during tests. Each case builds a fresh store and handler so tests are fully isolated — no shared state leaking between cases. The `w.Body.String()` in the error message means a failing test prints the actual response body, which cuts debug time significantly.\n\n### Benchmarks: Built Right In\n\nBenchmarks follow the same file and naming conventions as tests, but use `*testing.B` and prefix with `Benchmark`. The runner calls your function repeatedly, adjusting iteration count until the timing is stable:\n\n\n\n func BenchmarkStoreList(b *testing.B) {\n s := store.NewInMemoryStore()\n\n // seed 1000 orders\n for i := 0; i < 1000; i++ {\n s.Create(model.CreateOrderRequest{\n Customer: fmt.Sprintf(\"customer-%d\", i),\n Amount: float64(i) * 1.5,\n })\n }\n\n b.ResetTimer() // don't count seeding time\n\n for i := 0; i < b.N; i++ {\n _, err := s.List()\n if err != nil {\n b.Fatal(err)\n }\n }\n }\n\n\nRunning `go test -bench=. -benchmem ./store/...` gives you nanoseconds per operation and allocations per operation:\n\n\n\n BenchmarkStoreList-8 42361 28204 ns/op 24576 B/op 3 allocs/op\n\n\n`b.ResetTimer()` after the seeding step is the habit that matters most here — you want to measure `List`, not `Create × 1000`. The `-benchmem` flag surfacing allocations per operation is the other one: in a hot path, allocation count matters as much as raw speed.\n\n### The go test Habits Worth Locking In\n\nAfter a few weeks of writing Go tests, these are the ones I've made automatic:\n\n**Always use`t.Run` for multi-case scenarios.** Even two cases. The named sub-test output pays for the extra line immediately when something breaks.\n\n**`t.Parallel()` for independent tests.** Adding `t.Parallel()` at the top of a test (or sub-test) tells the runner it can execute concurrently with other parallel tests, cutting total test time on multi-core machines with no other changes.\n\n**`-race` in CI, always.** Data races in Go are silent in normal test runs and catastrophic in production. The race detector adds overhead but catches things that would otherwise survive code review and only surface under load.\n\n**`testify/assert` if your team agrees, `testing` if they don't.** The standard `testing` package requires writing your own error messages for every assertion. `testify/assert` gives you `assert.Equal`, `assert.NoError`, and friends with good default messages. Both are valid choices — the important thing is consistency within a codebase.\n\n### Up Next\n\nPart 7 is the finish line: multi-stage Docker build, graceful shutdown, and getting this service onto ECS Fargate — the same deployment target I used for `rust-ai-gateway`. The testing patterns from this post will feed directly into the CI pipeline we wire up there.\n\nDo you have a preferred Go testing library — pure `testing`, `testify`, or something else? Curious whether the standard library alone is enough once the projects get bigger.",
"title": "Testing in Go — Table-Driven Tests, Benchmarks, and go test Habits"
}