What do MockK's @MockKExtension.ConfirmVerification and @MockKExtension.CheckUnnecessaryStub class annotations make happen, when do they run, and what is the cost of switching them on across a whole test suite?

## The two switches MockK's JUnit 5 extension carries a small family of nested annotations. Two of them turn the extension from a setup/teardown helper into a **strictness enforcer**: - `@MockKExtension.ConfirmVerification` — at cleanup time the extension invokes MockK's global `confirmVerified()` (no arguments, i.e. every registered mock). If a mock recorded a call that no `verify`/`coVerify` block matched, the test fails. - `@MockKExtension.CheckUnnecessaryStub` — at the same point it invokes `checkUnnecessaryStub()`, which fails the test when a stub was recorded but never exercised. One asks "did you look at everything that happened?", the other asks "did everything you set up actually matter?". They attack opposite ends of the same sloppiness. ## Where and when they run They are not separate callbacks — they live inside the extension's normal cleanup routine, which runs **after each test method** under JUnit's default per-method instance lifecycle, or **after the whole class** when the class is annotated with the per-class lifecycle. The order inside that routine matters and is worth knowing: 1. `unmockkAll()` (unless suppressed), 2. `confirmVerified()` if `ConfirmVerification` is on, 3. `checkUnnecessaryStub()` if `CheckUnnecessaryStub` is on, 4. `clearAllMocks()` in a `finally`. The `finally` is deliberate: a failing strictness check must not leave the next test staring at a polluted mock registry. Note also the per-class consequence — with the per-class lifecycle the checks see the *accumulated* interactions of every test in the class, which is almost never what you want; these switches fit the default per-method lifecycle. ## How they are enabled Both annotations target a **class** (unlike `KeepMocks`, which also works on a single method). Both are `@Inherited`, and the extension searches annotations recursively through meta-annotations, so a project can define one custom annotation that carries `@ExtendWith(MockKExtension::class)` plus the strictness switches and apply that everywhere. Both also have a suite-wide equivalent as a JUnit Platform configuration parameter — `mockk.junit.extension.confirmverification` and `mockk.junit.extension.checkUnnecessaryStub` (mind the casing of the second) — supplied through the platform's configuration file or as a system property. The extension enables a check when **either** the class annotation **or** the configuration parameter says so. That OR is the important operational detail: once the property is set globally there is no per-class opt-*out* annotation. A single legacy test class that cannot satisfy the check will hold the whole property hostage, which is the main argument for adopting the annotations class by class first and only later considering the global switch. ## What it costs you **Every test becomes an interaction test.** Without `ConfirmVerification`, a test asserts the outcome it cares about and ignores the rest; with it, any call the subject makes on any mock is a potential failure unless verified. Refactors that add a legitimate collaborator call now break tests that had nothing to do with that behaviour — the classic brittleness complaint about strict interaction testing, applied automatically to your whole class. **Relaxed mocks get noisy.** A relaxed mock answers everything, so subjects freely call logging, metrics and audit sinks on it. Those calls are recorded and therefore must be verified or explicitly excluded from the record. **Shared setup stubbing breaks.** A `@BeforeEach` that stubs five collaborator methods for the convenience of the whole class will trip `CheckUnnecessaryStub` in every test that only needs three of them. The intended fix is to move stubbing into the tests that need it, which is genuinely better practice but is a real migration cost on an existing suite. **Failures land in teardown.** The stack you see points at the extension's cleanup, not at the line that stubbed or called. The message content is what identifies the offending mock and call, so read it rather than the location. ## How to adopt them sensibly Start with `CheckUnnecessaryStub` — it flags dead setup, which is nearly always a genuine defect and rarely encodes a design opinion. Add `ConfirmVerification` selectively, on classes where the interaction *is* the contract: an event publisher, an outbound gateway, a retry policy. Leave it off for tests whose subject legitimately chatters at relaxed sinks, or clean the record for that noise. And treat any global configuration parameter as a decision for the whole repository, because it cannot be waived per class.