Do we need to to the string for this check? Can't this be done on the parsed objects?

It's not that easy, I'm afraid. Both <testsuites> and <testsuite> can contain other testsuites. We need to distinct a <testsuites> root element from a <testsuite> root element because the name of the highest-level <testsuite> tag needs to be ignored. This means the name of a <testsuite> under the root <testsuites> is ignored, while the name of a <testsuite> under a root <testsuite> is kept because the root's name is ignored.

I looked for a way to check for the root tag with Jackson but wasn't able to find one. Any suggestions?

Could you have a boolean-parameter like testsuitesFound that gets passed through recursivly? This can be used to decided if the name should be appended, and the value gets changed one the level got round.

I'm not sure what you mean. The impact of the <testsuites> element is only on its direct child <testsuite> elements. All deeper nested <testsuite>s should have their names prepended.

I'm also not sure if my understanding of what you want to accive is correct now (Btw, if this is a quite complicated logic we should test all these cases and further extend the current server tests)

From my interpretation the main difference if wheter when traversing the nested testsuite and testsuites we have hit a point where we found a testsuites element. Then, the name construction below should only use the local name. So we can just pass a boolean-Parameter that tells the level below if the top-level is such a element, and then create the name accordingly.

Well, since you wrote hightest level we would need anotother boolean to indicate if we already found one such element before. With that, we should have all information we neeed (what is me parent, and was that parent the first such element) to create a fitting name.

Again, this behaviour should be documented and tested. I can already see it breaking just becuase the next developer didi not even know about testsuites in testsuites.

There isn't really a JUnit XML standard, but I have been using this as a reference: https://github.com/testmoapp/junitxml

<testsuites> can only ever appear as the root element. It cannot not appear anywhere else in the document.

Some tools choose to use <testsuite> as the root element. This should be handled equivalent to a <testsuite> as the single direct child of a root <testsuites>.

The Jenkins parser previously only supported a <testsuite> root element. Root <testsuites> are stripped with a regex. The name of this root <testsuite> was not needed for disambiguation, since no other <testsuite>s can appear on the root level. But deeper <testsuite>s can have siblings, so their name is needed for disambiguation.
We need to keep this naming behavior for backwards compatibility.

With <testsuites> as the root element, we can have multiple <testsuite> elements on the level where their names would be ignored. In this case, we do need their names to disambiguate the different hierarchies.

The possible cases are:

<testsuites>
  <testsuite name="ignored">
    <testsuite name="included">
      ...
    </testsuite>
  </testsuite>
<testsuites>

<testsuite name="ignored">
  <testsuite name="included">
    ...
  </testsuite>
</testsuite>

<testsuites>
  <testsuite name="included A">
    <testsuite name="included">
      ...
    </testsuite>
  </testsuite>
  <testsuite name="included B">
    <testsuite name="included">
      ...
    </testsuite>
  </testsuite>
<testsuites>

Because this only affects the first or second level elements, it's enough to handle them before the recursion.

I think the confusion comes from the equal parsing of <testsuites> and <testsuite>. I can create a distinct record to make it clear that no further <testsuites> should occur.

I also get that the documentation/naming is confusing. How can we improve this?