Add file and line attributes #16
Conversation
Location information isn't an official part of the JUnit XML spec, so various conventions have emerged for reporting locations such as within the name attribute, inferring from the classname using project structure assumptions, or including it in the content of the testcase node (as we do). At least one tool[^1] that reads JUnit reports will look for file and line attributes if present on the testcase node. To better support this and any similarly-behaving tools, let's add them. [1]: mikepenz/action-junit-report
Co-authored-by: Evan Borden <[email protected]>
I do not know what this means, can you rephrase? |
Are there competing standards for tracking this info in JUnit? |
itemLocation is almost always present, but in the case of a positioned
result it differs from that in meaningful way:
it "does a thing" $ do // <-- itemLocation
x <- this
y <- that
x `shouldBe` y // <-- itemResultLocation
Therefore, we should prefer itemResultLocation but can fallback to
itemLocation if it's missing. This gets a best-effort location of the
"it" for cases without positioned results (e.g. Success), as visible in
the golden.xml diff.
My best answer to that question is the PR description 🤷 I was going by this Stack Overflow which basically says "there is no spec", this comment, which says "line numbers are not consistent between output formats", and then this source which does a bunch of guess work (if If you have any knowledge of a stronger convention than adding these two attributes explicitly do let me know. The maintainer of the GitHub Action is super nice and would be willy to look for whatever we provide -- especially if we have a standards-based reason for it. |
|
When I implemented |
|
Looks like it adds a |
|
Ha, fair enough. |
Location information isn't an official part of the JUnit XML spec, so
various conventions have emerged for reporting locations such as within
the name attribute, inferring from the classname using project structure
assumptions, or including it in the content of the testcase node (as we
do).
At least one tool* that reads JUnit reports will look for file and
line attributes if present on the testcase node. To better support this
and any similarly-behaving tools, let's add them.
* mikepenz/action-junit-report