In the Maven Surefire report schema, what does the `<properties>` block inside a `<testsuite>` hold, and why can a fact about one individual `<testcase>` never be recorded there?

middleshould knowfreq 38%

answer

a name and a value, both attributes
it hangs off the suite
no per-case equivalent exists
no key is ever required
convention, not contract

basics

~20 s

<properties> holds a flat list of <property> elements, each carrying a @name and a @value attribute. It is a child of <testsuite>, so everything in it describes the whole file - <testcase> has no properties block of its own.

solid answer

~40 s

<properties> is a <testsuite> child holding <property> elements, and each <property> carries its pair as two attributes, @name and @value - not as text content, and not as nested elements. It is the format's only general-purpose name-and-value channel, which is why writers use it to describe the run: environment, toolchain, build coordinates. Because it hangs off <testsuite> rather than <testcase>, everything in it is scoped to the whole file, so a fact that differs between two cases in the same suite has nowhere to live. The schema also fixes nothing about the content: no key is required, no vocabulary is reserved, no value is typed, and nothing stops two <property> elements sharing a @name. A consumer reading a particular key is coding against a convention it observed, not against the format.

`<properties>` is a `<testsuite>` child holding `<property>` elements, and each `<property>` carries its pair as two attributes, `@name` and `@value` - not as text content, and not as nested elements. It is the format's only general-purpose name-and-value channel, which is why writers use it to describe the run: environment, toolchain, build coordinates. Because it hangs off `<testsuite>` rather than `<testcase>`, everything in it is scoped to the whole file, so a fact that differs between two cases in the same suite has nowhere to live. The schema also fixes nothing about the content: no key is required, no vocabulary is reserved, no value is typed, and nothing stops two `<property>` elements sharing a `@name`. A consumer reading a particular key is coding against a convention it observed, not against the format.

code

xml · 7 lines

xml

<testsuite name="com.example.CartTest" tests="1" errors="0" skipped="0" failures="0">
  <properties>
    <property name="env" value="ci"/>
    <property name="branch" value="main"/>
  </properties>
  <testcase name="addsItem" classname="com.example.CartTest" time="0.104"/>
</testsuite>

go deeper

for a junior

Know that <properties> sits under <testsuite> and holds <property> elements, each with a @name and a @value attribute rather than text content.

for a middle

Explain the scoping consequence: because the block hangs off the suite, it describes the whole file and cannot express anything that varies from case to case.

for a senior

Talk about relying on it in a real pipeline - unreliable keys across writers, blocks that disagree between files of one run, and where you enforce the values instead.

for a principal

Set the policy: which provenance keys every writer your teams own must emit, and how that gets checked, given the format guarantees no key at all.

The format's only name-and-value channel

The Maven Surefire report schema gives <testsuite> a <properties> child, and <properties> holds <property> elements. Each <property> carries its pair as two attributes: @name and @value. There is no text content to read and no nested key/value structure. That flat list is the only general-purpose channel the format offers for information which is not a test outcome, so it is where writers put the description of the run itself: the environment, the toolchain, the build's own coordinates.

Where the block sits, and what that scopes it to

<properties> is a child of <testsuite>. It is not a child of <testcase> -- the case element's content model has no properties block in it. Everything a <properties> block says is therefore scoped to the whole suite, which in practice means the whole file.

In the suite's content model the block also comes before the <testcase> elements, so a streaming reader has the run's description in hand before the first case arrives.

That single structural fact decides a great deal:

A per-case fact has nowhere to go. If two cases in one suite ran against different inputs, browsers or fixtures, the format has no field in which to record the difference.
The block does not vary within a file. A reader can parse it once and attach the same values to every row it renders.
Consolidating several files means consolidating several blocks, and they can disagree -- two suites from one run may honestly report different values for the same key.

What the schema does and does not fix

It fixes the shape: a <properties> container, <property> children, @name and @value on each. It fixes nothing whatever about the content. There is no required key, no reserved vocabulary, no type for a value, and no rule that two writers use the same key for the same idea. A consumer that looks for a particular key is coding against a convention it observed, not against the format.

The consequences are worth stating plainly:

Every key is optional. Code that assumes a key is present fails on the first file from a different writer.
Every value is a string. Anything numeric or boolean is your parse and your problem.
Key collisions are unresolved. Nothing forbids two <property> elements with the same @name in one block, and the schema does not say which of them wins.
Absence means nothing in particular. A missing key may mean the fact was not true, or that this writer simply never emits it.

Using it well

Treat the block as provenance you chose to write, not as a lookup table you can rely on. If your pipeline depends on a value being there -- the branch, the environment, the build identifier -- then the step that produces the file is the place to guarantee it, and a check at ingest is the place to notice when it stops arriving. Keep key names stable across every writer you own, because a renamed key looks exactly like a missing one to everything downstream.

And when you find yourself wanting to record something about one case rather than about the suite, recognise that as the format's ceiling rather than as a puzzle to be solved inside it. Anything per-case that the format has no field for does not survive the round trip, and a consumer written against the schema will never go looking for it.

## The format's only name-and-value channel The Maven Surefire report schema gives `<testsuite>` a `<properties>` child, and `<properties>` holds `<property>` elements. Each `<property>` carries its pair as two attributes: `@name` and `@value`. There is no text content to read and no nested key/value structure. That flat list is the only general-purpose channel the format offers for information which is not a test outcome, so it is where writers put the description of the run itself: the environment, the toolchain, the build's own coordinates. ## Where the block sits, and what that scopes it to `<properties>` is a child of `<testsuite>`. It is not a child of `<testcase>` -- the case element's content model has no properties block in it. Everything a `<properties>` block says is therefore scoped to the whole suite, which in practice means the whole file. In the suite's content model the block also comes *before* the `<testcase>` elements, so a streaming reader has the run's description in hand before the first case arrives. That single structural fact decides a great deal: - **A per-case fact has nowhere to go.** If two cases in one suite ran against different inputs, browsers or fixtures, the format has no field in which to record the difference. - **The block does not vary within a file.** A reader can parse it once and attach the same values to every row it renders. - **Consolidating several files means consolidating several blocks**, and they can disagree -- two suites from one run may honestly report different values for the same key. ## What the schema does and does not fix It fixes the shape: a `<properties>` container, `<property>` children, `@name` and `@value` on each. It fixes nothing whatever about the content. There is no required key, no reserved vocabulary, no type for a value, and no rule that two writers use the same key for the same idea. A consumer that looks for a particular key is coding against a convention it observed, not against the format. The consequences are worth stating plainly: 1. **Every key is optional.** Code that assumes a key is present fails on the first file from a different writer. 2. **Every value is a string.** Anything numeric or boolean is your parse and your problem. 3. **Key collisions are unresolved.** Nothing forbids two `<property>` elements with the same `@name` in one block, and the schema does not say which of them wins. 4. **Absence means nothing in particular.** A missing key may mean the fact was not true, or that this writer simply never emits it. ## Using it well Treat the block as provenance you chose to write, not as a lookup table you can rely on. If your pipeline depends on a value being there -- the branch, the environment, the build identifier -- then the step that produces the file is the place to guarantee it, and a check at ingest is the place to notice when it stops arriving. Keep key names stable across every writer you own, because a renamed key looks exactly like a missing one to everything downstream. And when you find yourself wanting to record something about one case rather than about the suite, recognise that as the format's ceiling rather than as a puzzle to be solved inside it. Anything per-case that the format has no field for does not survive the round trip, and a consumer written against the schema will never go looking for it.

One report is built from several of these files, each carrying its own `<properties>` block with different values for the same key. What should the consumer do?
Decide explicitly, because the format does not. The blocks are per file and may honestly disagree - different suites can run in different environments. Merging silently invents a value that no file asserted; keeping them per suite is truthful but makes a single run-level banner impossible. Whichever you choose, make it visible to readers.
Can a consumer rely on a particular property key being present?
No. The schema requires no key, reserves no vocabulary and types no value, so a key is only as reliable as the writer emitting it. Code defensively, and if your pipeline depends on a value, guarantee it in the step that produces the file and check for it at ingest rather than assuming it.

It is the label on the outside of the crate, not a note tucked in beside each item. One label describes the whole shipment, and there is nowhere on the crate to write something true of only one item inside it.

saying these in an interview costs you the question

Thinks <testcase> can carry its own <properties>
Expects a value as element text, not @value
Assumes a standard set of required property keys
Treats property values as typed rather than strings
Merges several files' blocks without saying so

In the Maven Surefire report schema, what does the `<properties>` block inside a `<testsuite>` hold, and why can a fact about one individual `<testcase>` never be recorded there?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

The format's only name-and-value channel

Where the block sits, and what that scopes it to

What the schema does and does not fix

Using it well

▾common follow-ups2 questions

▾analogy~20 s

▾red flags5 flags

The format's only name-and-value channel

Where the block sits, and what that scopes it to

What the schema does and does not fix

Using it well

answer

go deeper