A test that cannot fail is not a test
We shipped a texture treatment across eighteen pages. The check confirmed the CSS class was present in the HTML. It was present. The check passed.
Nothing was rendering, because the class did not exist in the stylesheet.
What went wrong
A module offered a texture option that mapped a choice to a CSS class, and the map emitted texture--image-grain. The stylesheet defines texture--image and texture--grain as two separate classes, and the page that looked correct was composing both.
So the class name in the map was real in the sense that it was a string, and unreal in the sense that no stylesheet had ever heard of it. Eighteen pages shipped with a class that styles nothing.
The verification looked for texture--image-grain in the page HTML. Of course it was there. We had just written it.
The same mistake, two days earlier
Chasing a copy change that would not appear on a live page, an earlier check searched the template source for minutes with a bit of trailing context. It matched minutes, save and resume, which was a different sentence, and never showed the word immediately before it, which was the word that was supposed to have changed.
That looked like confirmation. It confirmed nothing.
Different feature, different tooling, identical error: asserting on a string I had written rather than on the behavior I wanted.
The rule
Assert against something independent of your change.
In the texture case, the independent source was the stylesheet. The correct check was: for every class this module can emit, does a matching selector exist in the CSS? That check can fail. It would have failed. It would have caught it before a single page shipped.
In the copy case, the independent source was the live page rather than Design Manager, and the correct assertion was on the changed word itself.
The test is simple to apply. Ask what would have to be true for this check to fail. If the answer involves your own edit not having happened, the check is only telling you that your file save worked. That is not what you wanted to know.
Where this bites hardest
Anywhere two things have to agree and nothing enforces it. A module's class map and the stylesheet. A workflow's property name and the property. A template's variable and what the page actually provides.
Each of those pairs can drift, both halves look fine on their own, and a check written against either half alone will always pass.
We also found the same broken class map in a second module, which had not shipped yet and would have failed the moment anyone selected that option. That one was found by grepping the stylesheet for every class any module could emit, which is the check that should have existed from the start.