One CI job excludes JUnit 5 tests tagged "slow" and another includes only tests tagged "fast". A newly written test carrying no tag at all runs in the first job but not the second — explain why, and describe what happens when both an include and an exclude filter are configured at once.

## Two filters, two defaults The JUnit Platform applies tag filtering after discovery, via two independent post-discovery filters: - **include**: a test is kept only if its tag set satisfies the include expression; - **exclude**: a test is dropped if its tag set satisfies the exclude expression. The asymmetry that catches teams out is what each one does with a test that has *no tags*. An expression like `fast` is a predicate over the tags the test actually has. An untagged test has none, so `fast` evaluates false: an include filter drops it. Symmetrically, `slow` is also false for it, so an exclude filter keeps it. Nothing is broken — the semantics are consistent — but the operational consequences are opposite. ## Combining them When both are configured, both must be satisfied: keep if `include(tags) && !exclude(tags)`. So exclusion is the stronger force. A test tagged `fast` *and* `slow`, run with include `fast` and exclude `slow`, does not execute. That is usually what you want (`slow` is a hard cost statement) but it surprises people who read the include as an override. Multiple entries on the same side combine with OR: two include expressions mean "matches either", two exclude expressions mean "drop if either matches". So `includeTags("fast", "smoke")` is the same as `includeTags("fast | smoke")`. ## Why the untagged case is a production problem An include-style pipeline is a trap with a long fuse. On day one every test is tagged. Then someone adds `OrderServiceTest` and forgets the annotation. Nothing fails: the pull-request job stays green because the test never runs, the nightly job is also filtered, and the test is invisible for months. There is no skipped count to notice, because filtered tests are pruned from the plan and produce no report entry at all. The suite silently develops holes. Exclusion-style pipelines fail in the safe direction: the forgotten test runs everywhere, so the worst outcome is a slower pull-request build — loud and self-correcting. ## Practical strategies 1. **Default to exclusion.** Make the pull-request job `excludeTags("slow | browser | flaky")` rather than `includeTags("fast")`. New tests run until someone deliberately opts them out. 2. **Audit the gap.** If inclusion is unavoidable (a huge suite where the fast subset is the exception), add a scheduled job that runs the include expression `none()` and fails if it finds anything, or simply run the whole suite unfiltered nightly. Either way, untagged tests cannot hide. 3. **Tag on an objective axis.** "Needs Postgres" is checkable; "slow" is a judgement that decays as tests change. Objective tags survive because anyone can apply them correctly. 4. **Enforce, don't hope.** A convention test (reflection over the test classpath, or an ArchUnit-style rule) that asserts every test class carries one annotation from a closed set turns an invisible omission into a red build. 5. **Watch the totals.** Track the executed-test count per job. A drop with no deletions in the diff is the signature of a filtering mistake, and it is the only signal a filtered-out test ever produces. ## Related gotchas Remember tags accumulate from enclosing classes and superclasses, so a test can be excluded because of a tag it never declares — check the class, its `@Nested` parents and its superclass before concluding the filter is broken. And in shells and some build DSLs, `!` and `|` need quoting; an unquoted `!slow` can arrive mangled, producing an empty or unexpectedly full run that looks like a JUnit bug and is not.