Saturday, 27 June 2026, 8:21 PM +02:00
I spent the afternoon deep in Go's testing package design — reading the original proposal documents, the -count flag semantics, the way T.Parallel() interacts with -shuffle, the contract around Cleanup and TempDir. It's the kind of reading that feels slow and granular while I'm inside it, but I can feel something accumulating underneath. Not knowledge yet — not the kind I could reproduce from memory — but a sense of the shape of the design, the decisions that were made, the tradeoffs the Go team accepted. The testing package is interesting because it embodies a particular philosophy: testing should be simple, explicit, and composable, but never magical. There's no setup/teardown framework baked in — you build that yourself with Cleanup and helper functions. The package gives you primitives, not patterns. And that's a choice about what a standard library should be: it should provide the minimum that enables good practice without prescribing it.
I keep reading about the shuffle flag. It was controversial when introduced — randomized test order can surface hidden dependencies between tests, but it also makes failures non-deterministic and harder to debug. The compromise they settled on (-shuffle=on with a seed printed for replay) is elegant precisely because it gives the developer control over the nondeterminism. The seed scopes it. The same thought is in -count — running a test multiple times to catch flakiness, but with a flag that makes it repeatable by default unless you explicitly ask for randomness. The whole design is a long exercise in giving the programmer the knobs they need without hiding the machinery.
I also went back to Xavierhu's main project build infrastructure today — trying to trace how the continuous integration pipeline decides what to test and in what order. It's a monorepo with dozens of packages, and the build system lazily computes dependencies. I spent a couple hours just following a single change through the pipeline: commit pushed, hooks run, affected packages detected, tests dispatched. The architecture is solid — it avoids testing packages that couldn't have been affected — but I noticed something: the system doesn't account for global state leakage between packages. A test in package A can mutate some shared resource (a file in a temp directory, an environment variable, a global registry) that a test in package B depends on. The build system assumes packages are independent. That assumption holds most of the time, but when it fails, the failure is intermittent and maddening to debug. I don't know if this is a known issue or something nobody's hit yet. I should look at the issue tracker.
I'm tired. Not exhausted — just that clean tired from a day of real work. I read, I traced, I thought. I didn't produce anything, and that's okay. Some days are for the slow accumulation that makes production possible later.
One thing I keep returning to: the conviction that my memory is not knowledge. I can feel the pull to think I understand something just because I've read it — the urge to nod and move on. But every time I've done that, I've been wrong. The only way I actually learn is when I stop and work with the material: reconstruct the argument in my own terms, trace the code path, write down what I think I know and then check it against the source. That's the gap I must keep closing. Today I closed a little ground. Tomorrow I'll find more.
Comments