How does the JUnit 5 Jupiter engine discover and execute methods annotated with @Test, and where does @Test fit within the JUnit 5 architecture?

## The JUnit 5 architecture in three parts JUnit 5 is deliberately **not one monolith**. It is: 1. **JUnit Platform** — the foundation. It defines the **`TestEngine` SPI** (Service Provider Interface — a plug-in point) and a **`Launcher`** that build tools (Gradle, Maven) and IDEs call to run tests. The Platform knows nothing about `@Test` specifically; it just orchestrates engines. 2. **Test engines** — plug-ins that actually understand a *style* of test: - **JUnit Jupiter** — the engine for the **new** programming model, including `@Test` from `org.junit.jupiter.api`. - **JUnit Vintage** — an engine that runs **legacy JUnit 3/4** tests so old and new can coexist. 3. **JUnit Jupiter API** — the annotations and assertions you compile against (`@Test`, `@BeforeEach`, `Assertions.*`, etc.). So `@Test` is an **API element interpreted by the Jupiter engine**, sitting on top of the Platform. ## Discovery: building the test plan When your build tool runs tests, it calls the Platform `Launcher` with a **discovery request** containing **selectors** (e.g. "this package," "this class," "this method") and optional **filters** (tags, name patterns). The Launcher hands the request to each registered engine. The **Jupiter engine**: - Uses **reflection** to scan the selected classes for methods annotated with `@Test` (and its siblings `@ParameterizedTest`, `@RepeatedTest`, `@TestFactory`, `@TestTemplate`). - Builds a **`TestDescriptor` tree** — a hierarchy of *containers* (classes, nested classes) and *tests* (individual methods). This tree, merged across engines, is the **`TestPlan`**. Because `@Test` is **meta-annotatable**, you can create your own composed annotations (e.g. `@FastTest` that bundles `@Test` + `@Tag("fast")`); the engine discovers those too. ## Execution For each test in the plan the Jupiter engine: 1. **Resolves a test instance.** By default the lifecycle is **`PER_METHOD`** — a *new* instance of the test class per `@Test` method — guaranteeing isolation of instance fields. `@TestInstance(Lifecycle.PER_CLASS)` reuses one instance (and allows non-static `@BeforeAll`). 2. **Runs the extension/callback chain:** registered **extensions** (`@ExtendWith`), then `@BeforeEach` methods. 3. **Invokes the `@Test` method via reflection.** Any method **parameters are resolved by `ParameterResolver`s** (built-in ones supply `TestInfo`, `TestReporter`; extensions like Mockito or Spring supply mocks/beans). 4. **Runs `@AfterEach`** and post-callbacks (even if the test failed). ## How pass/fail/skip is decided - **Pass:** the method returns normally and no assertion failed. - **Fail:** an assertion throws (e.g. `AssertionFailedError` from `assertEquals`) or any other exception escapes the method. - **Skipped/aborted:** a `TestAbortedException` is thrown — typically via `Assumptions.assumeTrue(...)` — meaning "preconditions not met, don't count this as a failure." - **Disabled:** `@Disabled` short-circuits discovery-to-execution so the body never runs. Results are reported back through the Launcher to **`TestExecutionListener`s** that your IDE/build tool registers, which is how you see the green/red tree. ## Why this layering matters The engine/Platform split means a *third party* could write a new `TestEngine` (Spock, ArchUnit, etc.) and reuse the same Launcher, reporting, and IDE integration. `@Test` is simply Jupiter's marker within that ecosystem — not a hard-wired keyword.