Testing on

Lesson 10: Test Architecture — Tests that survive refactoring

Tue, 25 Mar 2025 00:00:00 +0000

Every test suite starts clean. Then the codebase grows, the team grows, deadlines hit, and gradually the tests become the thing you dread touching. You add a feature and a hundred tests break — not because the feature is wrong, but because the tests were coupled to implementation details. You rename a method and spend more time updating tests than writing the feature. Sound familiar? The problem isn’t the tests themselves. It’s the architecture — the structure, the layering, and the principles that determine whether your test suite stays an asset or becomes a liability.

Lesson 9: Flaky Test Control — A flaky test is worse than no test

Sat, 15 Feb 2025 00:00:00 +0000

A flaky test is a test that sometimes passes and sometimes fails with no code change in between. It sounds like a minor annoyance. It’s actually corrosive. Once your team learns that the test suite sometimes fails for “no reason,” they start merging on red. They start dismissing failures. They lose trust in the test suite as a signal. A single reliably-failing test is informative; a dozen flaky tests teach your team to ignore failures. I’ve seen this destroy test suite culture on multiple teams.

Lesson 8: Race-Aware Tests — If it passes without -race, it hasn't passed

Mon, 20 Jan 2025 00:00:00 +0000

A test suite that passes without -race is not a clean bill of health. It’s a test suite that hasn’t checked one of the most insidious categories of bugs in Go: data races. I’ve shipped code that passed every test, passed code review, and then caused memory corruption in production because two goroutines were reading and writing a map concurrently. The race detector would have found it in under a second. We just never ran it.

Lesson 7: Golden File Testing — Store expected output, compare on run

Thu, 05 Dec 2024 00:00:00 +0000

Some functions produce output that’s too large or too structured to assert inline. A template renderer, a code generator, a JSON serializer for a deeply nested type, a CLI help text formatter — any of these can produce hundreds of lines of output that you need to verify is correct. Hardcoding that expected output inside the test function creates a wall of string literals. The golden file pattern solves this by storing the expected output in a file, comparing against it at test time, and offering a flag to regenerate it when the output intentionally changes.

Lesson 6: Mocking Alternatives — Interfaces over mocks, always

Tue, 05 Nov 2024 00:00:00 +0000

Mocking has a bad reputation in the Go community, and some of it is deserved. Not because mocks are inherently wrong, but because the way most people use them — generating verbose stubs from interfaces, asserting on call counts, verifying argument order — produces tests that are coupled to implementation details rather than behaviour. Refactor the internals of a function without changing its public contract, and suddenly half your mocks break. That’s not a test problem. That’s a mock-as-test-double problem.

Lesson 5: Database Testing with Testcontainers — Mock the DB and you mock the truth

Thu, 10 Oct 2024 00:00:00 +0000

I used to mock databases. I had a clean Store interface, a MockStore implementation for tests, and 100% coverage on my service layer. I felt good about it. Then we migrated from MySQL to PostgreSQL and discovered that a dozen subtle behaviours we’d been mocking around were wrong — UPSERT semantics, NULL handling in GROUP BY, timestamp precision, transaction isolation differences. The mock had been lying to us for months. Testcontainers fixed that.

Lesson 12: Test Architecture — When to unit, integration, or e2e

Sun, 08 Sep 2024 11:10:00 +0000

I inherited a Rust project with 800 tests. Running them took 45 minutes. I dug in and found: 600 unit tests that mocked every dependency (most tested nothing meaningful), 180 integration tests that duplicated what the unit tests already covered, and 20 end-to-end tests that were flaky because they hit a staging server. The project had more tests than any codebase I’d seen — and also more bugs. The volume was high, but the strategy was garbage.

Lesson 11: Testing in CI — GitHub Actions for Rust

Thu, 05 Sep 2024 16:45:00 +0000

I merged a PR last year that passed all tests on my M2 MacBook and broke on the Linux CI runner. The issue? I’d used std::path::PathBuf with hardcoded forward slashes, which worked fine on macOS but blew up on Linux because the test setup expected a specific path format. CI exists to catch exactly this kind of “it works on my machine” problem. Here’s how to set it up properly for Rust.

Lesson 10: Benchmarking with criterion — Measure, don't guess

Mon, 02 Sep 2024 13:20:00 +0000

I once optimized a hot loop by replacing a HashMap lookup with a Vec indexed by a precomputed key. Felt clever. Ran the benchmarks. The “optimized” version was 15% slower because the Vec was huge, cache-cold, and the access pattern was random. Without the benchmark, I would’ve shipped that “improvement” and bragged about it. Performance intuition is unreliable. Measurement isn’t.

The Problem

Rust is fast by default, but that doesn’t mean your code is fast. You can still write O(n^2) algorithms, cause cache thrashing, allocate unnecessarily, or clone data you could borrow. Worse, optimizations that seem obvious can backfire in ways you don’t expect.

Lesson 4: HTTP Handler Testing — httptest is your best friend

Sun, 01 Sep 2024 00:00:00 +0000

Every Go HTTP handler is just a function that takes a ResponseWriter and a *Request. That’s the entire contract. The fact that the standard library ships with a testing package that lets you call that function with a fake writer and a real request — without starting a server, without binding a port — is a gift that too many people overlook. I spent months spinning up actual servers in tests before I discovered net/http/httptest. I will not let you make the same mistake.

Lesson 9: Code Coverage — tarpaulin and llvm-cov

Fri, 30 Aug 2024 07:55:00 +0000

I worked on a team that had a strict “90% code coverage” policy. Every PR had to hit that number or it got rejected. The result? People wrote tests like assert!(true) just to touch lines. We had 92% coverage and bugs everywhere. Coverage is a useful signal. It’s a terrible goal.

That said, knowing which lines your tests don’t touch is genuinely valuable. It tells you where your blind spots are. Here’s how to measure it in Rust.

Lesson 8: Snapshot Testing with insta — Catch regressions instantly

Tue, 27 Aug 2024 10:30:00 +0000

I refactored a code formatter once — changed how it handles indentation for nested blocks. I had assertions checking specific outputs for five test cases, and they all passed. But the formatter produced subtly different output for a sixth pattern I hadn’t tested, and a user filed a bug three days later. If I’d had snapshot tests, I would’ve seen every output change in a diff during the refactor. Five minutes of review instead of three days of embarrassment.

Lesson 7: Fuzz Testing with cargo-fuzz — Breaking your code automatically

Sat, 24 Aug 2024 20:05:00 +0000

A friend of mine maintains a binary parser in Rust. It had hundreds of unit tests, property tests, the works. He ran a fuzzer against it on a Friday afternoon, left it running over the weekend. Monday morning: 23 unique crashes. Some were panics from unexpected inputs. Two were infinite loops. One was a stack overflow from deeply nested structures. All from inputs no human would ever think to construct.

Lesson 6: Property-Based Testing with proptest — Let the computer find your bugs

Thu, 22 Aug 2024 15:40:00 +0000

I wrote a URL parser once. Had fifty hand-crafted test cases. All green. Pushed to production. Within a week, a user sent a URL with a percent-encoded space followed by a Unicode character, and the parser crashed. I never would have thought to write that test case. A property-based test would have found it in under a second.

The Problem

When you write tests by hand, you test the cases you think of. But bugs don’t live in the cases you think of — they live in the ones you don’t. Your test for sort([3, 1, 2]) passes, but does your sort handle a list with ten million duplicates? A list of all negative numbers? An empty list? A list with i32::MAX and i32::MIN adjacent?

Lesson 5: Mocking — mockall and faking dependencies

Mon, 19 Aug 2024 08:15:00 +0000

I spent an embarrassing amount of time early in my Rust journey trying to mock a database connection by hand. I built a fake struct, implemented the trait, tracked method calls with RefCell<Vec<...>> wrappers, wrote expectation-checking logic… and ended up with 200 lines of mock code to test 15 lines of business logic. Then I found mockall and felt like an idiot.

The Problem

Real code has dependencies. Your payment processor calls Stripe. Your user service queries a database. Your notification system sends emails. You can’t — and shouldn’t — hit these real services in unit tests. They’re slow, flaky, expensive, and non-deterministic.

Lesson 4: Test Fixtures and Setup/Teardown — Reusable test infrastructure

Sat, 17 Aug 2024 11:30:00 +0000

I had a test file last year where every single test started with the same twelve lines of setup — creating a database connection, inserting seed data, configuring a logger. Twelve lines, copy-pasted forty times. When I needed to change the seed data, I had to update forty tests. I missed three. Those three tests silently tested against stale data for two months.

Fixtures exist to prevent this kind of insanity.

Lesson 3: Doc Tests — Tested documentation

Wed, 14 Aug 2024 18:10:00 +0000

I once read the docs for a popular Rust crate, copied the example verbatim, and it didn’t compile. The API had changed two versions ago but nobody updated the docs. I spent twenty minutes debugging code that was supposed to be the “getting started” guide. Rust has a built-in solution to this exact problem, and it’s one of the most underappreciated features in the language.

The Problem

Documentation lies. Not on purpose — it lies because code evolves and docs don’t. A function signature changes, a parameter gets renamed, a return type shifts from String to &str, and the example in the docstring quietly becomes fiction. No compiler warning, no test failure, just a frustrated user copy-pasting broken code.

Lesson 2: Integration Tests — The tests/ directory

Mon, 12 Aug 2024 09:45:00 +0000

A colleague once reviewed one of my Rust libraries and said, “Your unit tests pass, but I can’t actually use the crate — the public API doesn’t compose the way anyone would expect.” He was right. I’d tested every internal function meticulously and completely ignored the experience of someone actually calling my library from the outside. That’s the gap integration tests fill.

The Problem

Unit tests live inside your source files and can access private functions. That’s great for verifying internal logic, but it creates a blind spot: you never validate that your public API actually makes sense. You can have perfect internal functions that combine into a terrible user experience.

Lesson 1: Unit Tests — #[test] and assertions

Sat, 10 Aug 2024 14:22:00 +0000

I shipped a Rust library last year that had zero tests. Not because I’m lazy — I was prototyping, moving fast, “I’ll add tests later.” You know how that story ends. A one-character typo in a boundary check sat in production for three weeks before someone’s data got silently corrupted. Three weeks. I’d have caught it with one assert_eq! and thirty seconds of effort.

Never again. Here’s how testing actually works in Rust, from the ground up.

Lesson 3: Integration Tests — Unit tests lie, integration tests prove

Thu, 01 Aug 2024 00:00:00 +0000

Unit tests feel productive. You write a function, you write a test, everything goes green, and you merge. But unit tests exist in a bubble — a bubble where every dependency returns exactly what you told it to return. The real world doesn’t do that. Your database serializes a time.Time differently than you expect. Your HTTP client follows a redirect your mock never mentioned. Your message queue drops a message under backpressure that your fake queue cheerfully delivered. I’ve had unit test suites where every test passed and the feature didn’t work in staging. Integration tests are what close that gap.

Lesson 2: Fuzzing in Go — Let the machine find your edge cases

Wed, 10 Jul 2024 00:00:00 +0000

There’s a class of bugs that you will never find by thinking about edge cases. You’ll think about empty strings, about zero values, about negative numbers. But will you think about the string that’s exactly 65,536 bytes? Or the UTF-8 sequence that’s technically valid but trips up a specific parser codepath? Or the floating point value that serializes and then fails to deserialize because of a precision edge in your JSON handling? You won’t. But a fuzzer will find it in under a minute.

Lesson 1: Subtests and t.Run — Name your test cases or debug blind

Sat, 15 Jun 2024 00:00:00 +0000

I used to write tests the way I wrote the first functions I ever wrote in Go — flat, repetitive, and with names so generic that when they failed, I had no idea which case broke. “TestParseDate failed” is not information. It’s a dare. Go figure out which of the twelve implicit cases in the body is responsible. I wasted hours doing exactly that before I committed to subtests.

t.Run is one of those language features that looks like a small convenience and turns out to be load-bearing for any serious test suite. Once you start using it, you wonder how you ever shipped anything without it.