Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SUREFIRE-2224] StatelessXmlReporter#getTestProblems() does not properly reflect report schema structure #702

Merged
merged 1 commit into from Dec 22, 2023

Conversation

michael-o
Copy link
Member

Following this checklist to help us incorporate your
contribution quickly and easily:

  • Make sure there is a JIRA issue filed
    for the change (usually before you start working on it). Trivial changes like typos do not
    require a JIRA issue. Your pull request should address just this issue, without
    pulling in other changes.
  • Each commit in the pull request should have a meaningful subject line and body.
  • Format the pull request title like [SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles,
    where you replace SUREFIRE-XXX with the appropriate JIRA issue. Best practice
    is to use the JIRA issue title in the pull request title and in the first line of the
    commit message.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Run mvn clean install to make sure basic checks pass. A more thorough check will
    be performed on your pull request automatically.
  • You have run the integration tests successfully (mvn -Prun-its clean install).

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

@michael-o
Copy link
Member Author

michael-o commented Dec 21, 2023

@NissMoony have a look. A preluding simplification to your PR.

@michael-o michael-o marked this pull request as draft December 21, 2023 14:29
@michael-o
Copy link
Member Author

I believe that this one is incomplete and requires a full ticket with a fix.

…rly reflect report schema structure

This closes #702
@michael-o michael-o marked this pull request as ready for review December 21, 2023 15:38
@michael-o
Copy link
Member Author

@kriegaex Have a look at this one as well. I am not happy that stackTrace is under this variable as well, but maybe just because it is internal (not public) it does not matter much.

@michael-o michael-o changed the title Simplify condition for nested output/error elements [SUREFIRE-2224] StatelessXmlReporter#getTestProblems() does not properly reflect report schema structure Dec 21, 2023
@kriegaex
Copy link
Contributor

@michael-o, actually, I am a bit out of context here and not 100% sure what that code does and currently am busy otherwise, i.e. I am just looking at the code here on the website, which IMO is not a good way to conduct a proper review. You have to check out the code and see what it does, inspect/run tests covering the code etc.

It looks as if in case of reported test errors or failures, it adds something like an "error" or "failure" tag to the XML and then, if any stack trace exists, also a "stackTrace" element and "system-out"/"system-err".

Am I seeing correctly, that you just refactored the code with no functional changes, only reflecting the nesting structure of the XML output in the logical structure (if block) of the source code? If so, it looks good to me.

@michael-o
Copy link
Member Author

@michael-o, actually, I am a bit out of context here and not 100% sure what that code does and currently am busy otherwise, i.e. I am just looking at the code here on the website, which IMO is not a good way to conduct a proper review. You have to check out the code and see what it does, inspect/run tests covering the code etc.

It looks as if in case of reported test errors or failures, it adds something like an "error" or "failure" tag to the XML and then, if any stack trace exists, also a "stackTrace" element and "system-out"/"system-err".

Am I seeing correctly, that you just refactored the code with no functional changes, only reflecting the nesting structure of the XML output in the logical structure (if block) of the source code? If so, it looks good to me.

Just refactoring and abiding to the XML schemas: https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report.xsd and https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report.xsd

@asfgit asfgit merged commit 6eb7d7e into master Dec 22, 2023
25 checks passed
@michael-o michael-o deleted the simplify branch December 22, 2023 19:48

extraEscapeElementValue(stackTrace, outputStreamWriter, ppw, fw);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still needs to be called if stackTrace != null and !enableNestedOutErrElements. Otherwise, error and failure elements won't contain the stack trace as their content.

Copy link
Member Author

@michael-o michael-o Jan 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I understand what you mean. Let me rephrase and I guess you are right here, the schema is poorly designed. According to https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report.xsd both failure and error aren't complex elements, thus do not contain stackTrace. Their element body contains the strack trace? Is that the case, if so I will cancel the vote and work on a fix and let you know.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's right.

Before (with 3.2.3 and earlier)

<testcase name="addsTwoNumbers" classname="com.example.project.CalculatorTests" time="0.014">
  <failure message="1 + 1 should equal 2 ==&gt; expected: &lt;3&gt; but was: &lt;2&gt;" type="org.opentest4j.AssertionFailedError"><![CDATA[org.opentest4j.AssertionFailedError: 1 + 1 should equal 2 ==> expected: <3> but was: <2>
  at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
  at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
  at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
  at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
  at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:563)
  at com.example.project.CalculatorTests.addsTwoNumbers(CalculatorTests.java:26)
  at java.base/java.lang.reflect.Method.invoke(Method.java:578)
  at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
  at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
]]></failure>
</testcase>

After this change

<testcase name="addsTwoNumbers" classname="com.example.project.CalculatorTests" time="0.014">
  <failure message="1 + 1 should equal 2 ==&gt; expected: &lt;3&gt; but was: &lt;2&gt;" type="org.opentest4j.AssertionFailedError"/>
</testcase>

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the confirmation. I will cancel the vote today, create an improvement request to change the schema in the next major to a complex element with stackTrace to align with the rest and another one to fix this regression. I will ping you as soon as I have something to test.

Copy link
Member Author

@michael-o michael-o Jan 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Vote canceled and repo dropped.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fix: #709

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants