A JUnit 5 suite has many tests switched off by @Disabled and by custom conditional annotations. Once a quarter you want one run that executes all of them without touching the code. What does the junit.jupiter.conditions.deactivate configuration parameter do, how do you supply it, and what are the caveats?

## What the parameter is JUnit Jupiter reads *configuration parameters* — plain string key/value pairs — to tune engine behaviour. `junit.jupiter.conditions.deactivate` is one of them, and it exists for exactly one purpose: to switch off `ExecutionCondition` extensions for a run, so that tests those conditions would have skipped are executed instead. Its value is a **comma-separated list of patterns**, and each pattern is matched against the **fully qualified class name of the condition implementation** — not against the annotation name, not against the test name. Wildcards use `*`: - `*` — deactivate every condition; - `org.junit.*` — every condition in `org.junit` and its subpackages (all the built-ins); - `*.DatabaseCondition` — one class regardless of package; - `*System*` — any condition class whose name contains `System`; - `com.example.FlagCondition, com.example.LicenceCondition` — an explicit list. A condition whose class name matches is **not evaluated at all**. It does not "return enabled"; the engine skips the evaluation, so the node proceeds as if that condition were never registered. ## Why the built-ins are included The conditional annotations are conditions: `@Disabled` is backed by `DisabledCondition`, `@EnabledOnOs` by `EnabledOnOsCondition`, `@EnabledIfEnvironmentVariable` by its own condition class, and so on. There is nothing privileged about them, so `junit.jupiter.conditions.deactivate=*` also runs everything annotated `@Disabled`. That is the headline use case: an occasional run that answers "of the tests we turned off, which ones actually still pass?" — cheap rot detection for a suite that has accumulated disabled tests over a year. ## How to supply it Configuration parameters reach the engine through three channels, all equivalent from Jupiter's point of view: 1. **JVM system property on the test JVM** — `-Djunit.jupiter.conditions.deactivate=*`. This is the natural choice for an ad-hoc or scheduled run because nothing in the repository changes. 2. **`junit-platform.properties`** — a properties file at the root of the classpath containing `junit.jupiter.conditions.deactivate=org.junit.*`. Good for a permanent, checked-in default; bad for an occasional audit, because it applies to every run. 3. **Programmatically via the `Launcher` API** — `LauncherDiscoveryRequestBuilder.request().configurationParameter("junit.jupiter.conditions.deactivate", "*")`, used when you drive JUnit yourself or from a custom runner. Inside an extension you can read the effective value with `ExtensionContext.getConfigurationParameter(String)`, which resolves through the same precedence. ## Caveats worth naming **It is a blunt instrument.** Deactivation is per condition class and global for the whole run. Deactivating everything means an OS-gated test runs on the wrong OS and a service-gated test runs without the service — those failures are expected noise, and someone must triage them. Prefer the narrowest pattern that answers your question: `*.DisabledCondition` to unmask only `@Disabled` tests, leaving genuine platform gates intact. **It does not touch runtime aborts.** A test that bails out mid-body via an assumption is not using a condition; it aborts during execution and no configuration parameter changes that. Only pre-execution `ExecutionCondition` evaluation is affected. **It changes only whether the condition is consulted.** It cannot flip a condition's answer — there is no "force disabled" mode — and it cannot deactivate conditions selectively per test class; the pattern is matched against condition classes for the entire run. **Failures are the point, not a defect.** A run with conditions deactivated is an audit, not a gate. Do not wire it into the pull-request pipeline where its noise trains people to ignore red; run it on a schedule and treat the output as a work list. ## Where it fits in a suite strategy Disabled tests are silent debt: they still compile, so they look maintained, but they verify nothing. Two mechanisms keep that debt visible — always requiring a reason on `@Disabled` (the reason appears in the skip output), and a periodic deactivated run that tells you which of those tests now pass, which fail for the original reason, and which fail for a brand-new reason because the production code moved on. The third failure class is the valuable one: it is a bug the suite would have caught if the test had been running. If you write your own conditions, keep the class names meaningful (`DockerAvailableCondition`, not `Cond1`), because those names are the handle by which anyone can later switch them off.