Your CI build is green, but a large share of its JUnit 5 tests are being aborted at runtime by unmet preconditions. How do you stop runtime skips from hiding real gaps in coverage?

## Why this decays silently A failed assumption throws `TestAbortedException`, which the engine records as aborted and reporters render as skipped. Green builds are the desired behaviour — that is the entire point of gating — but it means the failure mode of the mechanism is invisible. A renamed environment variable, an agent image that lost a package, a probe with a timeout now too short on a loaded machine: each silently removes coverage while every dashboard stays green. Unlike a flaky test, nothing ever draws attention to it. The second-order damage is cultural. Once developers learn that green does not mean "everything ran", they stop reasoning about coverage at all, and the suite's signal value collapses even for the parts that do execute. ## Make the number visible The first move is measurement. Standard XML reports carry skipped entries with messages, and the platform's listener API can capture aborted results directly. Publish per-build totals — executed, failed, aborted — and trend them. A jump from 12 skips to 400 is obvious in a chart and invisible in a green checkmark. Break it down by tag or package so "integration skips" and "platform-specific skips" are separate lines, since they have very different meanings. ## Turn expected environments into assertions Gating exists for environments that legitimately vary — a contributor's laptop without Docker, a machine on the wrong OS. It does not exist for environments the pipeline promises. The discipline: for each environment capability CI is supposed to provide, set an explicit marker (an environment variable meaning "containers are supported here") and add a single check that *fails* when the marker is set but the capability probe fails. Now a broken agent produces one red, well-named failure pointing straight at the infrastructure, instead of hundreds of skips. This is a small inversion with a large effect: the guard keeps protecting developer machines, while CI loses its ability to quietly opt out. ## Enforce a floor on what ran Even with markers, whole categories can vanish — a tag filter typo, a discovery problem, a fixture that aborts everything. A cheap backstop is a floor on executed tests: fail the build if a critical category executed fewer than an expected number, or zero. It is crude and needs occasional adjustment, but it catches the catastrophic case where a suite silently stopped running, which is exactly the case that survives every other control. ## Reason quality Mandate a message on every assumption, and make it name the missing thing: which variable, which host and port, which file. Two years later, a skip reading "assumption is not fulfilled" is unactionable archaeology. Enforce it in review; a lint rule or a simple grep in the pipeline can catch message-less calls. Go further and structure the reasons — a small helper that formats "skipped: <capability> unavailable (<detail>)" makes reports groupable and lets you count skips by capability rather than by test. ## Decide the permanent cases Run a periodic review of what is skipped everywhere. Each entry has exactly three honest outcomes: 1. **Provide the environment.** If the coverage matters, make CI able to run it — containers, a shared sandbox, ephemeral infrastructure. Often the skip has been masking an unwillingness to invest in test infrastructure. 2. **Replace it.** If the real dependency is impractical, substitute a contract test, a service virtualisation layer, or a narrower unit test that keeps some of the value with none of the environmental need. 3. **Delete it.** A test that has not executed in a year is not protecting anything. It still costs review time, compilation, and false confidence. Deleting is a legitimate, often correct decision, and version control keeps it recoverable. What is not an option is leaving it indefinitely and pretending the coverage exists. ## Guard against abuse of the mechanism Watch for assumptions whose condition is about the *result* rather than the *environment* — skipping when a value looks wrong, when running on the CI flag, when a previous step did not produce data. Those are failures wearing a skip costume, and they should be caught in review. The rule to state plainly: an assumption may describe where the test is running, never what the code did. ## The summary answer Skips are a legitimate tool with an invisible failure mode, so they need governance rather than prohibition: measure and trend them, assert the environments that are promised, floor the executed count, demand specific reasons, and periodically force each permanent skip into provide/replace/delete. That keeps green meaning something.