How do you make PER_CLASS the default test instance lifecycle for an entire JUnit 5 suite without annotating every class, using the junit.jupiter.testinstance.lifecycle.default configuration parameter — and what should make you hesitate?

## The configuration parameter JUnit Jupiter's instance lifecycle has a built-in default of `PER_METHOD`, but that default is itself configurable through a **JUnit Platform configuration parameter**: ``` junit.jupiter.testinstance.lifecycle.default = per_class ``` Accepted values are `per_method` and `per_class` (case-insensitive; an unrecognized value logs a warning and falls back to `per_method`). It applies to every Jupiter test class in the run that does not carry its own `@TestInstance` annotation. ## How to supply it Configuration parameters are a general JUnit Platform mechanism, and this one is read like any other. In increasing order of precedence: 1. **`junit-platform.properties`** — a plain properties file on the **test runtime classpath** (conventionally in the test resources root). Committed to the repo, so it applies to IDE runs and CI alike. 2. **A JVM system property** with the identical name, e.g. `-Djunit.jupiter.testinstance.lifecycle.default=per_class` on the test JVM. 3. **A launcher discovery request parameter**, when something drives the platform programmatically through the `Launcher` API (`LauncherDiscoveryRequestBuilder.configurationParameter(...)`) — this is what a custom runner or IDE integration can pass. Higher entries in that list win over lower ones, and **an explicit `@TestInstance` on the class beats all of them**. That last point matters: the parameter changes only the *default*, never an expressed choice, so a class annotated `@TestInstance(Lifecycle.PER_METHOD)` keeps per-method isolation even in a `per_class` suite. The same properties file is where you would put other Jupiter defaults (display-name generator, parallel execution settings, and so on), so teams that already have one tend to reach for it here too. ## Why the parameter exists It was added mainly for **language and codebase ergonomics**. In Kotlin, a `static` `@BeforeAll` requires a `companion object` plus `@JvmStatic`, which is noisy in every class; a suite-wide `per_class` default removes that ceremony once. Some teams also standardize on per-class instances because their test style builds fixtures in `@BeforeAll` and keeps them immutable. The parameter lets those teams express the decision in one place instead of on hundreds of classes. ## Why you should hesitate The default it flips is a **safety default**, and the flip is invisible where it matters. - **Locality of reasoning disappears.** A reader opening `OrderServiceTest.java` sees no annotation and reasonably assumes fresh-instance isolation. The actual behavior lives in a properties file they may never have opened. Every future test author inherits an assumption they did not make. - **It changes existing classes retroactively.** Classes written under per-method assumptions — a field appended to in each test, a mock re-created in the constructor — suddenly share state. Some will fail loudly, which is fine; the dangerous ones pass while quietly becoming order-dependent. - **Parallelism gets harder everywhere at once.** If method-level concurrency is on (or gets turned on later), every class now shares one instance across threads. - **IDE and CI can diverge** if the parameter is supplied as a system property in the build rather than as a committed properties file: a test behaves one way locally and another in the pipeline, which is a miserable debugging session. ## What to do instead Prefer explicitness with the same amount of typing: - Annotate the classes that genuinely need it. It is one line, and it is the line a reviewer reads first. - Or create a **composed annotation** — `@TestInstance(Lifecycle.PER_CLASS)` plus whatever else your integration tests need — and apply that. The intent is now named (`@IntegrationTest`), greppable, and documented in one place, while still appearing at the top of every class that uses it. - If you do flip the global default (a Kotlin codebase is the strongest case), pair it with guardrails: randomized method order in CI, method-level parallel execution enabled somewhere so races surface, and a review habit of questioning mutable fields in test classes. ## Interview framing The knowledge check is the parameter name, its two values and the three supply channels; the judgment check is recognizing that a global lifecycle flip trades a per-class, visible decision for an invisible, suite-wide one. Saying "I know how, and here is why I would still annotate the handful of classes that need it" is the answer that lands.