In Cucumber-JVM, which wins when the same cucumber.* option is set in cucumber.properties and by @ConfigurationParameter?

## One vocabulary, several places to say it Every Cucumber-JVM entry point speaks the same option namespace. `cucumber.glue` names the packages to scan, `cucumber.filter.tags` carries a tag expression, `cucumber.execution.dry-run` walks the run without executing steps, `cucumber.execution.parallel.enabled` switches concurrency on. What changes between entry points is not the *names* but the *places* those names can be written, and therefore which write wins. The places, from most specific to least: - **`@ConfigurationParameter` on a JUnit Platform suite class.** Bound to one suite, supplied as part of that suite's own discovery. It is code: it compiles, it is reviewed, and it moves with the suite. - **The platform's own configuration file at the classpath root.** A shared default for every suite in the module, overridable by a JVM system property. - **JVM system properties**, set with `-D` on the build command. The usual lever for varying a run from CI. - **Environment variables**, useful in containers where nobody controls the command line. - **`cucumber.properties` at the classpath root.** Cucumber's own file, the weakest layer, and the right home for values that are simply true of the project. The rule to say out loud in an interview is short: **the more specific source wins**, and `cucumber.properties` is the least specific thing there is. ## The command-line chain, which is explicit The command-line runner layers its configuration in a fixed order, each layer built on the one below: | Layer | Beats | Typical use | |---|---|---| | Command-line arguments | everything below | one-off and ad-hoc runs | | System properties (`-D`) | env vars and the file | per-stage overrides from CI | | Environment variables | the properties file | container images | | `cucumber.properties` | nothing | project-wide defaults | That ordering is the one people expect, and it is why a `-D` override feels natural. The trap is assuming the same reflex holds on a platform suite, where a value baked into the annotation is not something a command line was ever meant to displace. ## The design consequence, which is the real question Interviewers rarely want the ordering recited; they want to know whether you have been burned by it. The burn looks like this: a team hard-codes `cucumber.filter.tags` into `@ConfigurationParameter` so the pull-request build runs a fast subset, then wants the nightly build to run everything. They add `-Dcucumber.filter.tags=` to the nightly job, nothing changes, and the nightly quietly keeps running the fast subset for weeks. The fixes, in the order you should reach for them: 1. **Do not put varying values in the annotation.** Glue packages and the feature selector belong there — they are structural. Tag filters, parallelism and anything a stage tunes do not. 2. **One suite class per gating tier.** A fast suite and a full suite, each with its own hard-coded filter, is honest and readable, and both are discoverable in code review. 3. **Pass the varying value as a system property** and leave the annotation silent on that key, so the properties file supplies a default and CI supplies the override. 4. **Put genuinely global defaults in `cucumber.properties`** so a new suite class inherits them without repeating four annotations. ## Confirming which value actually took effect Never guess. The cheapest probe is a dry run: `cucumber.execution.dry-run` makes Cucumber walk discovery and step matching without executing any step body, so the scenarios selected and the steps matched tell you exactly which feature selection, tag filter and glue path were in force. A second, blunter probe is to set the key to a deliberately broken value — a glue package that does not exist — and see whether the run notices. If it does not, that source is not the one being read. ## Two files people conflate `cucumber.properties` and the JUnit Platform's own configuration file are different files with different owners. The first holds `cucumber.*` keys and is read on every Cucumber entry point, including the command-line and TestNG routes. The second is the platform's, holds platform keys, and is where a shared default for a platform run belongs. Writing `cucumber.*` keys into the platform file works on a platform suite and does nothing for a command-line run; writing platform keys into `cucumber.properties` does nothing at all. Say which file you mean, every time.