The Maven Surefire report schema declares `@time` and `@timestamp` on `<testsuite>` as optional, while `@time` on `<testcase>` is required. What may a consumer assume about a suite's duration and start time, and how should it behave when they are absent?
answer
- optional above, required below
- a case is always timed
- summing answers a different question
- absent is not zero
- setup belongs to no case
basics
~20 sNothing is guaranteed at suite level: @time and @timestamp are optional, so a valid file may carry neither. Only <testcase> @time is required, so a reader can sum case durations - which is a different quantity.
solid answer
~40 sOn `<testsuite>` both timing attributes are optional: `@time`, typed `xs:float`, and `@timestamp`, typed `xs:dateTime`, alongside `@version`, `@group` and `@flakes`. On `<testcase>`, `@time` is required while `@timestamp` is not. So a conforming file can tell you how long each case took and nothing about the suite as a whole. Summing the cases is the obvious fallback, but it answers a different question: the schema types the attribute without defining the interval it covers, class-level setup and teardown belong to no case, and cases running at the same time make the sum exceed elapsed time. Treat a missing `@time` as unknown rather than as zero, label a summed figure as total case time rather than suite duration, and take run timing from the job that ran the tests.
code
xml · 4 lines<testsuite name="com.example.CartTest" tests="2" errors="0" skipped="0" failures="0">
<testcase name="addsItem" classname="com.example.CartTest" time="0.104"/>
<testcase name="removesItem" classname="com.example.CartTest" time="0.088"/>
</testsuite>go deeper
Recall which timing attributes are optional: both on <testsuite>, while every <testcase> must carry a @time, so case durations are always available.
Explain why summing case durations does not reproduce a suite's duration - untimed setup and teardown, and cases that overlap when they run concurrently.
Show how you handle absence in a real reporting stack: unknown kept distinct from zero, derived figures labelled as derived, run timing sourced from the job itself.
Judge what timing evidence is allowed to gate a build, knowing that a threshold resting on an optional attribute passes quietly whenever the attribute is missing.
## What the schema says about time The Maven Surefire report schema declares two timing attributes on `<testsuite>` and both are **optional**: `@time`, typed `xs:float`, and `@timestamp`, typed `xs:dateTime`. They sit in the same optional group as `@version`, `@group` and `@flakes`. Down at case level the balance is different: `<testcase>` requires `@name` and `@time`, so a duration for an individual case is guaranteed, while `@classname`, `@group` and `@timestamp` are optional there. ## The asymmetry, in one table | element | `@time` | `@timestamp` | |---|---|---| | `<testsuite>` | optional | optional | | `<testcase>` | **required** | optional | So a perfectly valid file can tell you how long each individual case took while saying nothing about when the suite ran or how long it took overall. Any consumer that draws a duration bar, or orders suites on a timeline, has to survive that. ## Why summing the cases is not the same number When suite `@time` is absent, the obvious move is to add up the case durations. That produces *a* number, but not the same quantity, and the schema does nothing to make the two agree: - **The schema types the attribute and never defines the interval it covers.** Nothing says a suite's `@time` is wall clock, or that it is the sum of its cases. Two writers can both conform and mean different things by it. - **Work outside the cases is unaccounted for.** Class-level setup and teardown, service startup, fixture loading -- none of it belongs to a `<testcase>`, so none of it appears in the sum. - **Concurrency breaks addition outright.** If cases ran at the same time, the sum of their durations exceeds the elapsed time, sometimes by a large multiple. The honest label for a derived figure is therefore "total case time", not "suite duration". Presenting one as the other is how a report ends up claiming a suite took longer than the build that ran it. ## What `@timestamp` does not promise `@timestamp` is typed as a date-time, and a value of that type is not obliged to carry a zone offset. So two files can both conform and still not be safely comparable, and a consumer sorting suites by start time may be ordering values that were never expressed on the same clock. Where a file omits the attribute there is nothing to fall back on inside the format either: the case-level `@timestamp` is optional too. ## Behaving well when the attributes are absent 1. **Distinguish absent from zero.** A missing `@time` is an unknown duration; rendering it as `0.000` invents a fact, and it poisons averages and slowest-suite lists. 2. **Label derived numbers as derived.** If you summed the cases, say so in the interface, so nobody compares your figure against a writer-supplied one and concludes something changed. 3. **Take run timing from outside the file.** The job that ran the tests knows when it started and how long it took; that is a better source than an optional attribute, and it is there whether or not the writer emitted one. 4. **Do not build gates on optional attributes.** A duration threshold that silently passes whenever the attribute is missing is worse than no threshold at all. The general lesson is the one this whole schema keeps teaching: required means you can code against it, optional means you must code around it, and the file will not tell you which writer produced it.
- A dashboard renders a missing suite `@time` as 0.000. What does that break?Every aggregate built on it. Averages are dragged down, slowest-suite rankings put the unknown suite first as the fastest, and a duration trend shows a cliff that no change in the code caused. Unknown and zero are different facts, and a renderer that conflates them invents data the file never asserted.
- Why can two conforming files' `@timestamp` values be unsafe to compare?Because the declared type does not force a zone offset onto the value, so two writers can both conform while expressing start times on different clocks. Sorting suites by that attribute across files can therefore order them wrongly, and there is no fallback inside the format - the case-level `@timestamp` is optional too.
saying these in an interview costs you the question
- Renders a missing @time as a zero duration
- Calls the sum of case durations the suite duration
- Assumes @timestamp is present on every suite
- Builds a duration gate on an optional attribute
- Ignores that concurrent cases overlap when summing