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

[JENKINS-37598] Inaccurate aggregation of multiple xmls containing case information about the same testsuite #54

Merged
merged 2 commits into from
Aug 11, 2017

Conversation

kgyrtkirk
Copy link
Contributor

@kgyrtkirk kgyrtkirk commented Aug 22, 2016

JENKINS-37598

  • change logic to account for all suites involved during time aggregation in ClassResult
  • moved TestSuite merging code from TestResult to TestSuite.merge()
  • replaced TestSuite.time field with a boolean
  • added 2 testcases - 1 with time attributes; and 1 without them...added to TestResultTest (because of TestSuite.merge() call location)

@jglick jglick changed the title JENKINS-37598: Inaccurate aggregation of multiple xmls containing cas… [JENKINS-37598] Inaccurate aggregation of multiple xmls containing case information about the same testsuite Aug 29, 2016
// retrieve the class duration from these cases' suite time
duration = 0;
for (SuiteResult s : suites) {
duration += s.getDuration();
Copy link
Member

Choose a reason for hiding this comment

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

Seems like the simpler patch would just be

-if(duration == 0){
-    duration = r.getSuiteResult().getDuration();
-}
+duration += r.getSuiteResult().getDuration();

right?

Copy link
Member

Choose a reason for hiding this comment

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

BTW neither of the test cases seem to check that

<testsuites name="Automation Tests" tests="2" errors="0" failures="0" ignored="0">
    <testsuite name="test.fs.FileSystemTests">
     <testcase name="testPrefix1" classname="test.fs.FileSystemTest1" time="10"/>
     <testcase name="testPrefix1" classname="test.fs.FileSystemTest2" time="10"/>
    </testsuite>
    <testsuite name="test.fs.FileSystemTests">
      <testcase name="testPrefix2" classname="test.fs.FileSystemTest1" time="10"/>
    </testsuite>
</testsuites>

sums to 30.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i'm afraid not...and a change like that would be caught by the one of my new tests
in case not...i should add a case for this too ;)

..the for cycle is running thru cases...and the old trick was to only use the case runtime when the total is 0...the new code collects all the unique suites and aggregates there sum time

@kgyrtkirk
Copy link
Contributor Author

I've updated the testcases - should I squash my changes - instead of adding more commits?

About the mixed cases - i can detect it...but not sure what to do when that happens...throw an exception; or insert a "notice testcase" into the unit results?

    public void merge(SuiteResult sr) {
      if (sr.hasTimeAttr ^ hasTimeAttr){
          // addCase(new CaseResult(this, "__jenkins-junit-plugin_invalid-suite-merge", ""));
          // or throw new RuntimeException()
      }
      ...

@oleg-nenashev
Copy link
Member

I've updated the testcases - should I squash my changes - instead of adding more commits?

No need to do it. GitHub allows squashing during the merge

About the mixed cases - i can detect it...but not sure what to do when that happens...throw an exception; or insert a "notice testcase" into the unit results?

Exception is unlikely a good approach. I would merge with warning

@kgyrtkirk
Copy link
Contributor Author

@oleg-nenashev i've updated the changes; and included an exception for the mixed case (plus a test case for this mixed case too)

cheers

@kgyrtkirk
Copy link
Contributor Author

@oleg-nenashev: Can you please take a look at the updated changes?

@kgyrtkirk
Copy link
Contributor Author

@oleg-nenashev can you please take a look at this change?

@oleg-nenashev
Copy link
Member

@kgyrtkirk sorry, I was snowed under the stuff. Will try to review today.
Anyway, CC @jenkinsci/code-reviewers since more feedback is required

@kgyrtkirk
Copy link
Contributor Author

@jglick @oleg-nenashev - i've fixed the merge-conflict.

@@ -72,8 +72,8 @@
/** Optional ID attribute of a test suite. E.g., Eclipse plug-ins tests always have the name 'tests' but a different id. **/
private String id;

/** Optional time attribute of a test suite. E.g., Suites can use their own time attribute or the sum of their cases' times as before.**/
private String time;
Copy link
Member

Choose a reason for hiding this comment

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

If the class is being persisted on the disk, it requires a migration logic in readResolve()

Copy link
Member

Choose a reason for hiding this comment

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

Removal of this field will probably result in old data warnings. Should be made deprecated and transient instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh...I wasn't aware of this; in this case I think the best would be to live with existing 'time' field; and use it

/**
* Merges another SuiteResult into this one.
*
* @param sr
Copy link
Member

Choose a reason for hiding this comment

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

If you define the parameter in Javadoc, please add its description. Otherwise Javadoc linters will grumble

*/
public void merge(SuiteResult sr) {
if (sr.hasTimeAttr ^ hasTimeAttr){
throw new IllegalStateException("Merging of suiteresults with incompatible time attribute usage is not supported.( "+getFile()+", "+sr.getFile()+")");
Copy link
Member

Choose a reason for hiding this comment

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

Since you introduce a new method, it would be preferable to propagate a non-RunTime exception and to make the code above handle it. If you want to stick to IllegalStateException , it should be documented at least

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've changed this exception into a logger call...since the severity of this is not really critical - and theres no proper way to handle this elsewhere...so it will log a warning in this case.

@kgyrtkirk
Copy link
Contributor Author

@oleg-nenashev could you please take a look at this? I think the latest changes will look more promising :)

@kgyrtkirk
Copy link
Contributor Author

@oleg-nenashev , @jglick, @jenkinsci/code-reviewers could you please take a look at this patch?

Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

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

Looks good to me. Sorry for missing the previous ping

@kgyrtkirk
Copy link
Contributor Author

Could someone merge this? I would like to use this if possible from the next release (and drop the usage of a custom built plugin)

@olivergondza olivergondza merged commit d083744 into jenkinsci:master Aug 11, 2017
mfuchs added a commit to mfuchs/junit-plugin that referenced this pull request Aug 18, 2017
When running Android tests the <testsuite> in the generated xml file
can contain multiple classes.
Thus setting the test class duration to the value of the test-suite is wrong.

Instead the class duration is now calculated as sum its test cases.
This is the same way it was done before jenkinsci#35 was merged.
Reverting parts of both jenkinsci#35 and jenkinsci#54 did not break any existing tests.
bparees added a commit to bparees/origin that referenced this pull request Aug 30, 2017
since jenkinsci/junit-plugin#54 was merged,
it should not be needed anymore.
bparees added a commit to bparees/origin that referenced this pull request Aug 30, 2017
since jenkinsci/junit-plugin#54 was merged,
it should not be needed anymore.
bparees added a commit to bparees/origin that referenced this pull request Aug 31, 2017
since jenkinsci/junit-plugin#54 was merged,
it should not be needed anymore.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants