← sz3yan.com

#szejo ·

The type-checker said yes and the tests said nothing, because I never asked them

Symptom. None. That is the whole problem. I rewrote a page's data layer after the architecture underneath it changed — services that had been standalone were now modules inside another service, one…

2 min read

Symptom. None. That is the whole problem.

I rewrote a page's data layer after the architecture underneath it changed — services that had been standalone were now modules inside another service, one had been retired entirely, and the platform had moved from one orchestrator to another. Then I verified it: type-check clean, grep found no leftover references to the old names, and I clicked through every element in a browser and watched it render correctly. Reported it done.

Investigation. There was nothing to investigate, which is exactly why it took another task and an unrelated read of the repo to notice. The project had a test suite. The test suite asserted that certain words appeared in that data file — the names of the old orchestrator and its companion tool. Those assertions were correct when someone wrote them. My rewrite deleted every one of those words on purpose.

So the test was failing for the right reason, loudly, in a command I never ran.

Root cause and fix. Not the assertion. The test was doing its job. The failure was that "verified" got attached to a checklist that happened to exclude the single command that encodes what the data is supposed to say.

Consider what each check can actually prove. A type-checker proves the shape is legal. A grep proves a string is absent. A screenshot proves it renders. Not one of them can prove the content is still correct — and correctness of content was the entire subject of the change.

The fix was to rewrite the assertions against the real stack, then add a second test that fails if any of the retired names reappear anywhere in the file, and that every service still has a matching diagram. Now the next architecture change fails loudly instead of quietly shipping stale copy.

Lesson. When a repository has a test suite, running it is not one verification option among several. It is the one that encodes intent. Every other check describes the code as it currently is; only the tests describe what someone decided it should be. If your verification story does not include them, you have confirmed that your change is well-formed — not that it is right.