A test suite contains forty methods annotated @Disabled, some of them for more than a year. How would you handle disabled tests as a matter of engineering policy?

## Why disabled tests accumulate A skipped test is not a failure, so nothing in the pipeline pushes back. The person who disables it intends to come back; the person who inherits it does not know the story. Over a year, forty of them mean the green build overstates coverage by an unknown amount, and nobody can say by how much. The second-order harm is cultural: once disabling is the accepted response to a failing test, the suite stops being a gate and becomes a suggestion. ## Triage categories Every disabled test falls into one of four buckets, and the right action differs: 1. **Blocked** — the feature is not implemented, or an upstream dependency is not ready. Legitimate. Keep it, with a reason string naming the ticket, and expect it to disappear when the ticket closes. 2. **Flaky** — it passes sometimes. Disabling parks a real defect, in the test or in the system, and often in production behaviour. Either fix it, or delete it and record the gap. Parking indefinitely is the worst option because it preserves the illusion that the case is covered. 3. **Obsolete** — the behaviour no longer exists or was rewritten. Delete. Version control keeps the history; a skipped test does not. 4. **Environment-dependent** — it needs Linux, a licence key, a reachable sandbox. This is a misuse of `@Disabled`: it should be a conditional annotation or a custom `ExecutionCondition`, so it runs wherever the prerequisites hold and self-documents why it was skipped elsewhere. In my experience most long-lived skips are categories 2 and 4 wearing category 1's clothes. ## Making the debt visible - **Require a reason with a ticket.** `@Disabled("PROJ-1421: flaky under parallel execution")`. A reason-less `@Disabled` should not pass review. - **Report the inventory.** An extension implementing `TestWatcher` collects `testDisabled(context, reason)` and writes a list; publish it with the build so the number is seen, not merely available. - **Watch the trend, not the absolute.** A slowly rising skip count is the signal; the exact number matters less than its direction. - **Run a periodic audit** with conditions deactivated (`junit.jupiter.conditions.deactivate`) in a non-gating job. Tests that now pass get re-enabled; tests that fail get a fresh, accurate reason. This converts stale annotations into current information without anyone editing forty files by hand. - **Consider an expiry convention.** Some teams add a date to the reason and fail the audit job past it. Useful if the team will honour it; theatre if not. ## Where I would not go - **Blanket-deleting all forty** loses genuinely blocked cases that will come back. - **Failing the main build on any skip** sounds principled but drives people to comment tests out or delete them quietly, which is strictly worse: at least a skip is countable. - **Automatic retry as a flakiness cure.** It converts a visible skip into an invisible instability and delays the real diagnosis. ## The judgement call The underlying principle is that the suite must not lie. A test is either an assertion the team stands behind, or it should not be pretending to exist. `@Disabled` is a legitimate, temporary, *annotated* exception to that — with a reason, an owner and an expected end. Everything else is either fixed or removed.