Explain the tag-expression syntax the JUnit Platform uses to select tests: what do the operators !, & and | mean, what do the selectors any() and none() match, what is the precedence, and which characters are therefore illegal inside a @Tag value?
answer
- ! > & > |, parentheses to group
- any() = has ≥1 tag; none() = untagged
- tag value: no whitespace, no , ( ) & | !
- invalid tag → JUnitException at discovery
- case-sensitive, no spell-check
basics
~20 sTag expressions are boolean: ! (not), & (and), | (or), with that precedence, and parentheses to group — e.g. (micro | contract) & !flaky. any() matches any test with at least one tag, none() matches untagged tests. Because those symbols are grammar, a tag value cannot contain , ( ) & | ! or whitespace, and must not be blank.
solid answer
~50 sA tag expression is a boolean expression over tag names, accepted anywhere a tag filter is configured (Gradle `includeTags`/`excludeTags`, Maven `groups`/`excludedGroups`, ConsoleLauncher `-t`/`-T`). Operators, highest precedence first: `!` (not), `&` (and), `|` (or); parentheses override. So `fast | slow & !flaky` means `fast | (slow & !flaky)` — write the parentheses when in doubt. Two special selectors exist: `any()` matches every test that carries **at least one** tag, and `none()` matches every test that carries **no** tag. `none()` is the practical way to audit a suite for tests nobody labelled. Because the symbols form the grammar, the tag *value* is constrained: it must not be null or blank, is trimmed, must not contain whitespace or ISO control characters, and must not contain any of `,` `(` `)` `&` `|` `!`. Violating that is not silently ignored — discovery fails with a `JUnitException` naming the bad tag.
go deeper
Know the three operators and that parentheses exist; be able to read fast & !slow.
State the precedence, explain any()/none(), and connect the reserved characters back to the grammar.
Emphasise the untagged asymmetry and use none() as an audit; mention shell quoting of ! and | as a real failure source.
Argue for expressions simple enough to reason about — one axis, exclusion-based defaults — rather than clever nested boolean logic in CI config.
## The grammar A tag expression is boolean algebra over tag names. Four building blocks: - a bare tag name: `fast` — true when the test carries that tag; - `!expr` — negation; - `expr & expr` — conjunction; - `expr | expr` — disjunction; plus `(` `)` for grouping. Precedence runs `!` > `&` > `|`, exactly like `!`, `&&`, `||` in Java, and operators associate left to right. So `a | b & c` parses as `a | (b & c)`, and `!a & b` parses as `(!a) & b`, not `!(a & b)`. Getting this wrong is a real bug: `!slow & !flaky` (correct) versus `!(slow | flaky)` (equivalent) versus `!slow | !flaky` (almost everything, since a test rarely has both). ## any() and none() Two selectors are not tag names: - `any()` matches any test with **at least one** tag — useful as "everything somebody has classified"; - `none()` matches any test with **no tags at all**. `none()` is the audit tool. Running a job with `includeTags("none()")` lists exactly the tests that nobody labelled — the ones that will silently vanish from an include-style pipeline. `any()` and `none()` compose like anything else: `any() & !slow` is legal. ## Where expressions are accepted Anywhere a tag filter is configured a full expression is allowed, not just a bare name: Gradle's `includeTags` / `excludeTags`, Maven Surefire's `groups` / `excludedGroups`, the ConsoleLauncher's `-t` / `--include-tag` and `-T` / `--exclude-tag`, and IDE run configurations. Quoting matters at the shell and in build DSLs, since `!` and `|` are shell-significant — a mysteriously empty run is often a shell that ate the `!`. ## Tag naming rules follow from the grammar Since `&`, `|`, `!`, `(`, `)` and `,` are syntax, they cannot appear inside a tag value. The full rule set for a `@Tag` value is: - must not be `null` or blank; - the value is **trimmed**, and the trimmed value must not contain whitespace; - must not contain ISO control characters; - must not contain any of `,` `(` `)` `&` `|` `!`. So `@Tag("integration test")` and `@Tag("db&slow")` are invalid. This is *not* silently ignored: JUnit throws a `JUnitException` during discovery and the containing class is reported as an error, which is friendlier than an untagged test disappearing. Note what is *not* validated: case and spelling. `@Tag("Slow")` and `@Tag("slow")` are different tags, both perfectly legal, and nothing warns you — the argument for composed annotations over string literals. Hyphens, dots, underscores and colons are all fine, which is why namespaced conventions like `req:db` or `ci-nightly` are common. ## Worked examples - `fast` — only tests tagged fast. - `!slow` — everything except slow tests (including untagged ones). - `fast & !flaky` — fast tests that are not flaky. - `(micro | contract) & !browser` — either category, minus anything needing a browser. - `none()` — the untagged tests, i.e. your coverage gap in a tag-driven pipeline. ## The trap the grammar hides An expression is evaluated against the tags a test *has*. Untagged tests satisfy no bare name, so any include expression built only from positive names silently drops them; negative expressions like `!slow` keep them. That asymmetry is the single most common surprise with tag expressions and is worth stating out loud in an interview.
- How does the expression `fast | slow & !flaky` parse, and how would you write it if you meant the other grouping?`&` binds tighter than `|`, so it parses as `fast | (slow & !flaky)` — all fast tests, plus non-flaky slow ones. If you meant "fast or slow, but never flaky", write `(fast | slow) & !flaky`. Because the two differ only for flaky-and-fast tests, the mistake usually surfaces as an occasional red build rather than an obvious error.
- How would you find every test in the suite that carries no tag at all?Run the suite with the include expression `none()`, which matches exactly the tests with no tags. It is the standard audit for a pipeline whose main job includes positive tags, because those untagged tests are the ones being silently skipped everywhere. Some teams wire that as a scheduled job so untagged tests cannot accumulate unnoticed.
saying these in an interview costs you the question
- Assuming | binds tighter than & , or that evaluation is purely left-to-right
- Thinking any() means "all tests" rather than "tests with at least one tag"
- Using spaces or & inside a tag value and expecting it to work
- Believing an invalid tag value is ignored rather than failing discovery
- Assuming tag matching is case-insensitive so "Slow" and "slow" are the same tag