I relaxed a rule in my test suite, then wrote a short article to exercise the path it opened up. It shipped a page that quietly ignored three quarters of the files the build had made for it.
The rule was about image budget. Every article visual on this site is composed in code as a 1600 × 900 landscape master, and until last week each one also required a 900 × 1200 portrait master. That pairing was enforced by a test: a landscape file without its portrait counterpart failed the suite.
The requirement was too strong. A portrait recomposition earns its place when a landscape diagram stops being readable on a phone. A diagram with four short labels survives the width reduction intact, and building a second composition for it is production work with no reader on the other end. So I removed the pairing rule and replaced it with two narrower ones: the hero always ships both orientations, and a portrait master with no landscape parent is an error.
Nothing in the archive used the new case
That change created a permitted case that no article on this site had ever produced. Every existing diagram had a portrait counterpart, because until then the tests had demanded one. The newly legal path, a body diagram shipping landscape only, had never once been built.
I could have waited for the next real article to use it. That would have been the cheap choice, and it would have meant discovering whatever was wrong while trying to publish something I actually cared about.
Instead I wrote a throwaway. A real slug, a real Markdown body, a real generator with three compositions, a real entry in the image registry. Three paragraphs of honest prose about what the run was for, because a page of placeholder text would not have exercised the same code. Then I built it.
The mechanical part was as cheap as intended. Generating the masters and running the full static build took under a second combined. The parameterized image test picked the new article up from the registry with no test edit at all, moving the suite from 143 tests to 144. That much of the claim held.
The build made four files the page never mentioned
The landscape-only diagram was broken.
The build had done its job. It produced a full-size WebP and three width variants at 480, 960, and 1440 pixels. All four files sat on disk. The published markup referenced none of them, and served the 114 KB PNG instead of the 31 KB WebP sitting beside it.
Nothing was broken in the way tests usually mean. The image appeared. The file existed. The link resolved. The page was merely heavier than it needed to be, for a reason no page inspection would surface without checking the markup against the directory listing.
The cause was a guard I had written on purpose. Art-directed images need hand-written <picture> markup, and the responsive image pass must not rewrite those and clobber their media queries. So the enhancement step skips any <picture> block it finds. I had wrapped the throwaway's single diagram in <picture> out of habit, with no media query on it, and the build correctly identified it as markup to leave alone.
Why every test passed
This is the part worth separating from a point I made in the article about generating these images. That one was about aesthetic judgment: a test can confirm a file is 1600 pixels wide, but not that the composition is balanced, so a human has to look.
This failure is different, and less forgiving. Nothing here required taste. The correct behaviour was fully mechanical and completely checkable. Every image test I had was simply pointed at the wrong question.
does the file exist? asked, and answered yes
is the file referenced? never asked
The broken-image test walks the generated HTML and confirms every src and srcset points at a real file. It passes trivially on a page that mentions one asset and ignores four. The WebP tests verify that conversion works, which it did. Coverage was measured against the assets the page named, and the page named the wrong ones.
What I changed
The fix was markup, not build code. A single composition does not need a <picture> element at all. Written as a plain <img>, it flows through the normal path and the build wraps it into a complete <picture> with WebP sources, width candidates, a sizes attribute, lazy loading, and intrinsic dimensions.
The guard is a new test that reads the Markdown sources directly and fails on any <picture> without a media query, with an error message naming the file and saying what to write instead. I confirmed it failed on the bad markup before confirming it passed on the good.
Then I deleted the throwaway article, its generator, its images, and its registry entry.
What a smoke article does not do
It does not find defects you did not think to exercise. This one worked because I knew exactly which path had become reachable and deliberately took it. A throwaway written without that intent would have used the same well-trodden markup as every other article and passed cleanly.
It is also one defect, in one small repository, found once. The general claim I would defend is narrower than "write throwaway content": when you relax a constraint, the code path you just made legal has zero coverage by definition, and the cheapest thing to write next is the content that uses it. The tests you already have will not tell you, because they were written against the constraint you just removed.