[Issue-3226] JUnit5Xml30StatelessReporter does not change class name in report#3347
[Issue-3226] JUnit5Xml30StatelessReporter does not change class name in report#3347nils-christian wants to merge 3 commits intoapache:masterfrom
Conversation
… classname attribute When phrasedClassName was false, the classname attribute in the XML report incorrectly used sourceText (the @DisplayName value) whenever it was non-null, making the flag effectively a no-op for classes annotated with @DisplayName. The false branch now consistently uses getSourceName(), matching the existing pattern for phrasedMethodName. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
| false); | ||
| reporter.testSetCompleted(testSetReportEntry, stats); | ||
|
|
||
| FileInputStream fileInputStream = new FileInputStream(expectedReportFile); |
There was a problem hiding this comment.
please try with resources. I'm not sure if Xpp3DomBuilder close the FileInputStream
There was a problem hiding this comment.
Solved. I also added the fix for the other resources in the same test class. What about the failing workflow? The failures seem to be unrelated to my fix. Is this "normal"?
|
IT tests failure looks really legit. You should tell Claude to iterate over it, but using the |
|
Hi @olamy , Thank you. Unfortunately it seems that the issue becomes a rabbit hole. One of the tests (ArchUnit4IT) seems to rely on the previous (wrong) behaviour, where the display name was always used. The other failing tests indicate that the "sourceText" attribute is actually overloaded with semantic. The RunListenerAdapter fills the "displayName" attribute (which becomes "sourceText" in createReportEntry) with different values. For a non-nested test both the class name and the display name are filled based on the source. For a nested test the class name is filled with the name of the top class, but the display name is the one of the nested class. This also means that we would change the behaviour with our fix, as we now no longer write the nested class name (from "sourceText") into the report. Instead we write the top class name (or its display name) into the report. This would very likely break with the expectation of some clients. At the moment I am unsure how to continue with this bug. I still think that the original fix is correct, but the implementation of the adapter is, well, weird in my opinion. |
2 participants
Disclaimer: This PR has been implemented with the help of Claude Code.
This PR fixes #3226.