How does a disabled test interact with lifecycle callbacks, fixtures, and test reporting, and what risks come with accumulating disabled tests at scale?

## What 'skipped' actually means for execution A **lifecycle callback** is a method JUnit runs around your tests to set up and clean up shared state: `@BeforeEach`/`@AfterEach` run before/after *each* test method, and `@BeforeAll`/`@AfterAll` run once before/after *all* tests in the class. When a test is **disabled** (via `@Disabled` or a conditional annotation that resolves to disabled), JUnit determines this *before* attempting to run the test, so: - The **test method body does not execute**. - The **`@BeforeEach`/`@AfterEach`** callbacks tied to *that test* do not run for it - there is nothing to prepare or clean up. - Class-level setup (`@BeforeAll`) still runs once for the class if *any* test in it could run; a fully disabled class generally won't run its instance-level per-test fixtures for the skipped tests. The key takeaway: **don't rely on a disabled test's side effects** (e.g. it seeding data another test reads) - skipping it removes those side effects too, which can cascade into failures elsewhere. ## How it is reported A skipped test is counted in its **own category** - `skipped` - alongside `passed` and `failed`. It is *not* a pass. Build tools and CI dashboards typically show a skipped count and, for each, the reason: your `@Disabled("...")` string, or for conditionals an auto-generated message like 'Disabled on OS: MAC' or 'Disabled because property did not match'. This is why the reason string matters - it is your audit trail. ## The scale problem: silent coverage erosion The insidious risk is that **a fully green build can hide a large and growing set of skipped tests**. Each `@Disabled` quietly subtracts coverage while the suite still reports success. Over time this produces *false confidence*: code paths appear tested but aren't. Symptoms include rising skipped counts, disabled tests with stale or missing reasons, and 'temporary' skips that have outlived the bug they were parked for. ## Mitigations - **Make disabling accountable.** Fail CI on a `@Disabled` lacking a reason or a tracking ticket (lint/static analysis). - **Surface the signal.** Track and trend the skipped count; treat a rising number as a quality regression, not noise. - **Audit and prune.** Periodically review disabled tests to re-enable, fix, or delete - a disabled test that will never run should be removed, not left to rot. - **Prefer conditionals for environmental gating** so tests self-enable where valid, instead of being globally off. - **For flaky tests, weigh alternatives.** *Quarantine* (keep running but don't fail the build, collecting flake data) preserves signal better than a blunt `@Disabled`; fixing the root cause is best of all. Disabling is the easiest and most forgettable option, which is exactly why it accumulates. ## Bottom line `@Disabled` is a correct, useful escape hatch, but it is *state* you are adding to the codebase. Treat each disabled test as a small, tracked, time-boxed debt with an owner and an exit condition - not a silent permanent off-switch.