Explain how JUnit Jupiter's annotation lookup actually resolves an annotation such as @Tag or @ExtendWith: how deep does it follow annotations of annotations, and where besides the element itself does it search?

## The lookup algorithm JUnit's `org.junit.platform.commons.support.AnnotationSupport` (used by the Jupiter engine) implements a richer notion of presence than the JDK's `AnnotatedElement`: 1. **Directly present** — written on the element. 2. **Meta-present** — reachable by following the annotations *of* the element's annotations, recursively and to arbitrary depth. The walk skips the `java.lang.annotation` package (so `@Retention`, `@Target` and friends are not traversed) and tracks visited types so a cycle between two annotations cannot loop forever. 3. **Indirectly present via the hierarchy** — for classes, the same search is repeated on superclasses and on implemented interfaces (including interface default-method-bearing "test interfaces", a documented Jupiter pattern). For `@Nested` classes, enclosing classes are searched as well. Note what this implies: an abstract base test class annotated `@ExtendWith(MockitoExtension.class)` extends its extension to every subclass without `@Inherited`, and a test interface annotated `@Tag("contract")` tags every implementor. ## Single-valued versus repeatable This is where candidates usually stumble. - `findAnnotation(element, Test.class)` returns an `Optional` — the **first** match according to the search order, roughly: directly present, then meta-present, then up the hierarchy. Only one wins. - `findRepeatableAnnotations(element, Tag.class)` returns a **list**, and Jupiter *unions* what it finds. `@Tag` and `@ExtendWith` are `@Repeatable`, so a method annotated with a composed `@SlowTest` (itself `@Tag("slow")`) inside a class annotated `@Tag("integration")` inside an outer class annotated `@Tag("nightly")` carries all three tags. So composition **adds**; it does not replace. There is no way to "remove" a tag or an extension that a base class or meta-annotation contributed. If a category needs to opt out, model it as a different annotation rather than trying to subtract. Extensions found through this search are also **deduplicated by class**: registering the same extension class twice through two paths does not run it twice. ## What it does not do Jupiter deliberately has no attribute aliasing or attribute overriding — nothing like Spring's `@AliasFor`. A composed annotation cannot declare a parameter and forward it into the annotation it composes: `@TaggedAs("billing")` cannot become `@Tag("billing")`. Values baked into the meta-annotation are constants fixed at declaration time. When a category genuinely needs a parameter, the workarounds are: - declare one composed annotation per value (`@BillingTest`, `@ShippingTest`), which is what most codebases do and keeps the tag vocabulary closed and greppable; or - put the attribute on your own annotation and write an **extension** that reads it — `AnnotationSupport.findAnnotation(context.getElement(), TaggedAs.class)` inside an `ExecutionCondition`, `BeforeEachCallback` or `TestTemplateInvocationContextProvider`. The extension can act on the value, though it still cannot inject a tag into the descriptor after discovery. ## Why this matters in practice - Debugging "why is this test tagged/extended?" means looking at four places: the method, its composed annotations, the class, and the class's supertypes and enclosing types. - Deep composition chains are legal but hostile to readers. Two levels is usually the practical ceiling. - Because extensions accumulate up the hierarchy, a fat abstract base class quietly imposes cost on every subclass; composition on the annotation makes the same dependency explicit at the usage site.