Junit is parsed wrong

[Tattoo]

Hi!

We have used junitparser successfully for years, so thanks for that! Recently we were trying to upgrade the junitparser version we are using to a newer one -- we were stuck in the past for a long time. However, we ran into some troubles.

We have the following junit xml file:

<?xml version='1.0' encoding='UTF-8'?>
<testsuites>
  <testsuite name="suite1">

    <testsuite name="suite2">
      <properties>
        <property name="build" value="55"/>
      </properties>
      <testcase name="casea">
        <skipped/>
      </testcase>
      <testcase name="caseb">
      </testcase>
    </testsuite>

    <properties>
      <property name="build" value="55"/>
    </properties>
    <testcase name="case1">
      <skipped/>
    </testcase>
    <testcase name="case2">
      <error message="Example error message" type="the_error_type"/>
    </testcase>
    <testcase name="case3">
      <failure message="Example failure message" type="the_failure_type"/>
    </testcase>

  </testsuite>
</testsuites>

To open up the example, we have single suite (suite1) that has a subsuite (suite2) and also three test cases of its own. In turn, suite2 has two test cases of its own.

Before version 2.1.0, suite1.tests reported three test cases, whereas after that version, junitparser reports five. Same if you iterate over the test cases: you iterate also subsuite's test cases. In other words, subsuite's test cases "bubble up" to its parents test cases.

In our use case, we are transforming Junit xml's into another format that is reflective of the original Junit xml. Thus, this is undesireable for us, because now we would need to, on each level, filter any possible subsuite test cases.

To recap: - Last version that worked: 2.0.0 - First version that did not work: 2.1.0 - Tested all versions between 2.1.0 and 3.1.0

Or have I missed something on why this has changed?

[weiwei]

Interesting case. I changed because I assumed the current to be the correct behavior, but your exmaple also make sense.

I wonder if we can add a aggregate_tests switch during init that could toggle bewteen the two behaviors. It'll take some time because bandwidth is limited right now, but PRs are welcome.