RE: RE: Coin Bureau — Creator Content Thread (Volume 1)
You are viewing a single comment's thread from:

RE: Coin Bureau — Creator Content Thread (Volume 1)

Words
537
Reading
3 min
23d

Testing is the part of the work that nobody celebrates and everybody relies on. A feature that has never been exercised is not a feature, it is a hypothesis wearing a confident expression. The gap between code that compiles and code that behaves is wide enough to lose entire afternoons in, and the only bridge across it is the unglamorous business of actually trying the thing. What makes testing hard is not writing the assertions. It is choosing which assertions are worth writing, and then being honest enough to check that they would fail if the behaviour they describe disappeared. A test that passes whatever the code does is not a safety net, it is a decoration, and it is worse than nothing because it radiates a confidence it has not earned. The useful discipline is to break the thing on purpose, watch the test go red, and only then trust it to stand guard while you are not looking. There is a second trap underneath the first one. A test can be perfectly written and still point at the wrong place, anchored to a line number or a fragment of text that drifts the moment somebody reformats a file or adds an argument. The assertion survives, the intent quietly does not, and the suite stays green over a hole. Good tests describe behaviour rather than layout, and they locate what they are checking by structure rather than by how many bytes along it happened to sit on the day they were written. The third lesson is that passing locally proves less than it feels like it proves. Suites run in parallel, environments differ, caches lie, and a run that is green on one machine can be red on another for reasons that have nothing whatsoever to do with the change in front of you. A clean local run is evidence, not proof, and the difference between those two words is where most of the painful surprises live. There is also the matter of scope. It is tempting to test the thing you just wrote and call the job finished, but the invariants that actually break are rarely the ones you were thinking about. They live in files you never opened, in counters and allowlists and ratchets that somebody added years ago precisely because this class of mistake had already happened once. Running only the tests you touched is how you find out about those the hard way, in somebody else report rather than your own terminal. The final lesson is the one about honesty. A report that says everything passed is worth very little unless it also says what was run, on what, and what was deliberately left out. Silence about coverage reads as confidence, and confidence is exactly the thing a reader will borrow from you without checking. Say what you did not test, say what you could not test, and say which failures you decided were noise and why. That last one matters more than it sounds, because a flaky test dismissed without evidence is indistinguishable from a real failure dismissed without evidence, and the two are told apart only by the work you show. None of it is difficult, only easy to skip.