In an Allure run, what is the difference between `allure.properties` on the test code's classpath and an `environment.properties` file in the results directory?
answer
- same word, opposite ends of the run
- one is a classpath resource
- one sits beside the result files
- only the generator reads the second
- XML rows are keyed by key, not name
basics
~20 sallure.properties is a classpath resource the test run reads to configure Allure's writer. environment.properties is a file dropped into the results directory that only the report generator reads, to display name and value rows about the run.
solid answer
~40 s`allure.properties` belongs to the writer side. `allure-java` loads it from the classpath and then lets system properties override it, which is how keys such as `allure.results.directory` and `allure.link.issue.pattern` reach the adapter. It is never copied into the results directory and the report generator never looks for it there. `environment.properties` is the opposite: nothing in the test code writes it, and the generator reads it out of the results directory it was pointed at, turning each key and value into a row of the report's environment block. `environment.xml` carries the same block in XML form, and both live majors of Allure read both files. Because the block is just a file beside the results, whatever assembles that directory decides what goes in it.
code
xml · 12 lines<qa:environment xmlns:qa="urn:model.commons.qatools.yandex.ru">
<parameter>
<name>Browser</name>
<key>browser</key>
<value>Firefox</value>
</parameter>
<parameter>
<name>Test stand</name>
<key>stand.url</key>
<value>https://staging.example.org</value>
</parameter>
</qa:environment>go deeper
Know which of the two files sits on the classpath and which sits in the results directory, and be able to say that only the generator reads the environment one.
Explain the loading mechanics: allure-java reads allure.properties off the classpath and lets system properties win, while the generator reads the environment files out of whichever results directory it was pointed at.
Show that you treat the environment block as published output: it ships inside the report, so it is where a secret leaks and where a missing block leaves a report unreadable a month later.
Own the question of who writes the block and what belongs in it, so that every team's report carries the same keys and a report from another team is legible without asking them what they ran against.
Allure's pipeline has two halves that never meet. The **writer** - an adapter such as `allure-java` bolted onto a test run - produces a directory of `-result.json` and `-container.json` files. The **reader** - the report generator - is handed that directory and turns it into HTML. `allure.properties` and `environment.properties` sound like variants of one another. They belong to opposite halves, and confusing them is the fastest way to spend an afternoon on a report that stubbornly shows nothing. ## `allure.properties` - classpath, writer side `allure.properties` is a **classpath resource**, normally placed under a module's test resources. `allure-java` loads it in `PropertiesUtils.loadAllureProperties()`, which does three things in order: 1. reads `allure.properties` through the system class loader, 2. reads it again through the thread's context class loader, and 3. copies `System.getProperties()` over the result, so a value passed on the command line beats the file. The keys it carries configure the **writer**. `allure.results.directory` decides where result files are written (the default directory is `allure-results`). The link-pattern keys `allure.link.issue.pattern`, `allure.link.tms.pattern` and `allure.link.custom.pattern` turn the bare ticket id recorded by an `@Issue` or `@TmsLink` annotation into a URL, using `{}` as the placeholder. None of this becomes report content: it changes what the run writes, and where. The file is not copied into the results directory, and the report generator does not look for it there. Drop `allure.properties` beside your `-result.json` files expecting the report to pick it up and precisely nothing happens. ## `environment.properties` and `environment.xml` - results directory, reader side The environment block is the mirror image. Nothing in the test code writes it; it is an **ordinary file you place in the results directory**, and only the generator reads it. Both files are read by both live majors of Allure: - `environment.properties` - a plain properties file. Each key and value becomes one row of the report's environment block. Allure 2 reads it as UTF-8 and skips a leading byte-order mark if it finds one, falling back to the default properties decoding when the bytes are not valid UTF-8. - `environment.xml` - the same rows in XML. Each `<parameter>` element carries `<name>`, `<key>` and `<value>` children, **and the row is keyed on `<key>`, not on `<name>`**. Allure 2 and Allure 3 agree on this. `<name>` is parsed and then plays no part in identifying the row, which surprises everyone who fills in `<name>`, leaves `<key>` empty, and sees an empty block. Because the block is a file rather than something the adapter emits, whatever assembles the results directory decides its content: the browser and its version, the commit of the build under test, the region the suite was aimed at. ## Side by side | | `allure.properties` | `environment.properties` / `environment.xml` | |---|---|---| | where it lives | on the test run's classpath | in the results directory | | who reads it | the writer (`allure-java`) | the report generator | | what it changes | where results go; link patterns | a name-and-value block shown in the report | | who normally creates it | you, as a test resource | you or the job that gathers the results | | survives into the report? | no, only its effects do | yes, verbatim | ## A name collision worth knowing about in Allure 3 Allure 3's config file (`allurerc.js` and its siblings) has top-level keys named `environment`, `environments` and `allowedEnvironments`. Those are **not** this block. They split one report's results into named environments and live in the config, not in the results directory. Allure 3 still reads `environment.properties` and `environment.xml` out of a results directory exactly as Allure 2 does, and the rows they produce are a separate thing from the config keys that happen to share the word. ## The traps - **Putting a secret in the environment block.** Its contents are copied into the generated report verbatim. Reports get published where the team can open them and archived afterwards, so a token in `environment.properties` outlives the run that leaked it. - **Expecting the adapter to fill the block in.** It will not. An empty environment block is almost always a results directory nobody wrote the file into. - **Keeping both environment files in one directory.** Allure 2 reads the properties file first and then merges the XML entries over it, so on a shared key the XML value wins with no warning. Pick one file per results directory. - **Expecting a link pattern to be applied at generation time.** `allure.link.issue.pattern` is read on the writer side. By the time the generator sees a result, its links are either already resolved or they are not.
- If one results directory holds both `environment.properties` and `environment.xml` with the same key, which value does the report show?In Allure 2 the generator reads `environment.properties` first and then merges the `environment.xml` entries over the result, so on a shared key the XML value wins. Nothing warns you about the collision and the losing value simply never appears anywhere in the report. The cleanest answer is to keep one of the two files per results directory.
- Why is a credential a bad thing to put in `environment.properties`?The block is copied into the generated report verbatim, and reports are normally published where the whole team can open them and archived afterwards. A token or a connection string with a password in it therefore outlives the run that leaked it, in every copy of every report that was generated from that directory.
saying these in an interview costs you the question
- Thinks the Allure adapter writes environment.properties automatically
- Confuses allure.properties with environment.properties
- Expects the report generator to read allure.properties from the results directory
- Assumes environment.xml rows are keyed by their name element