Instead of repeating the JUnit 5 annotation @Tag("slow") as a string literal across hundreds of tests, how would you define a custom @Slow annotation that carries the tag, and what does that buy you?

## The mechanism JUnit 5 does not read annotations with a plain `getAnnotation` call. Its `AnnotationUtils` searches the annotation *graph*: an annotation on your test, an annotation on that annotation, and so on, plus enclosing classes and superclasses. An annotation that appears anywhere in that graph counts as present. That is what makes composed (meta-)annotations work, and it is the same mechanism behind `@Test` composites and custom `@ExtendWith` bundles. ## Writing one ```java @Target({ElementType.TYPE, ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) @Tag("slow") public @interface Slow {} ``` Three parts matter. `@Retention(RUNTIME)` is non-negotiable: the default is `CLASS`, which is dropped before reflection sees it, and the failure mode is silent — tests simply are not tagged and quietly disappear from an include-filtered run. `@Target` decides where it may be used; `TYPE` plus `METHOD` mirrors where `@Tag` itself is allowed (add `ANNOTATION_TYPE` if you want to compose further). And the `@Tag` value is still the plain string the build filters on. ## Why bother *Typo safety.* `@Tag("slwo")` compiles and runs, and the test just falls out of every tagged job forever. `@Slwo` does not compile. *Refactorability.* Renaming a tag across 800 files is a grep-and-hope with literals; with an annotation it is one edit inside the annotation declaration (plus the CI expression). IDE find-usages and "go to declaration" work on the annotation type, so the suite becomes navigable. *Bundling.* Composition is not limited to one tag. A realistic integration marker often reads: ```java @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Tag("slow") @Tag("db") @ExtendWith(PostgresExtension.class) @Timeout(120) public @interface DatabaseTest {} ``` One annotation now expresses the labels *and* the machinery. Tests get a single, meaningful opt-in and cannot end up tagged `db` while forgetting the extension that provides the database. *Governance.* A closed set of annotations is a vocabulary you can review; free-form strings drift into `slow`, `Slow`, `slow-test` and `slowish` within a year. Since tags are case-sensitive and unvalidated, that drift is invisible until a job runs the wrong set. ## Limits worth naming The annotation type is compile-checked, but the *link to CI is not*: the Gradle or Maven configuration still names the string `slow`, so renaming the tag value without updating the build silently changes what runs. Keep the value and the build config together in review. Also remember composition does not create scoping: `@DatabaseTest` on a class tags every test in it, including `@Nested` classes, exactly as a literal `@Tag` would. And because tags accumulate rather than override, a composed annotation adds its tags to whatever the enclosing class already declares. ## The JUnit 4 comparison Interviewers often ask how this differs from JUnit 4's `@Category(SlowTests.class)`. JUnit 4 used marker *types*, which gave type safety but also gave inheritance semantics (a category matched its subtypes) and required the class to exist. JUnit 5 chose plain strings plus meta-annotations: simpler engine, no inheritance magic, and you recover type safety yourself by composing an annotation — opt-in rather than built-in.