Package Name for Jenkins JUnit Reports

[tebuch]

When reporting xml output in Jenkins (using either JUnit test reports directly, or through xUnit plugin), the test report shows my tests under package name "(root)". It would be nice if:

• one could specify a package name either within the test code or as a command line argument OR
• the package name was the same as the class name or something similar.

From what I've researched, in order for Jenkins to recognize a package name for JUnit tests, the xml output needs to look something like this:
<testsuite classname="PackageName.ClassName" name="TestName".... </testsuite>
where PackageName is what would replace the ugly "(root)" in Jenkins

[tebuch]

Edit: I made a typo. The above should read <testcase classname="PackageName.ClassName" name="TestName" ...</testcase>

[shepmaster]

We are in the process of cleaning out old issues. If this issue still
applies to this version, please let us know, otherwise we're going to
close this issue to focus on current problems. Thanks for your report!

[jjrussell]

This is absolutely still an issue. However its even weirder. Some tests show up as packages whereas 16000 of them show up under the "(root)" package. I'm trying to find the pattern as to why some show up as packages and some show up under (root). The vast majority show up under (root).

The command I'm using is

RAILS_ENV=test RACK_ENV=test RUBY_HEAP_MIN_SLOTS=1000000 RUBY_HEAP_SLOTS_INCREMENT=1000000 RUBY_HEAP_SLOTS_GROWTH_FACTOR=1 RUBY_GC_MALLOC_LIMIT=1000000000 RUBY_HEAP_FREE_MIN=500000 time bundle exec rake -r 'ci/reporter/rake/rspec' ci:setup:rspec spec SPEC="${files[@]}" SPEC_OPTS="--format documentation --profile" --trace

What I see if very inconsistent parsing of what looks like the same basic test structure. A top level describe is sometimes the package, nested describes are sometimes the class and the it examples are sometimes the tests themselves.

Other times the package name itself is the full text of the top level describe andy nested context AND the example description itself. I don't see differences in the basic way my tests are formatted except for maybe the descriptions containing #name or .name etc. Not sure if that is relevant.

I think that putting all of the classes into the (root) package and so many classes showing up is causing jenkins to be painfully slow when parsing test results. The code appears to expect some packages, a larger number of classes and a yet larger number of tests under the class. The layout of so many classes is causing it heartburn.

[shepmaster]

@jjrussell What I'm not clear on is how the tests show up in a package at all. If @tebuch's info is correct, the classname attribute would need to be set, and I don't see that attribute in the code. I'd highly appreciate it if you could narrow down a test that gets a package name so we can figure out why.

Going back to the original request of having some way of manually specifying the package, I'm not sure of a clean way of doing that across all 5 testing tools we support. We also don't have the luxury of assuming that we are testing a class - Cucumber and Turnip tests blow that idea out of the water.

[jjrussell]

Hrm, let me see if I can put together a simple example.

[jperry]

any update on this?

[jjrussell]

I have not gotten back to this. Sorry. You can feel free to close this and when it annoys me again I'll come back with a PR or something.

[shepmaster]

@jperry Do you have some time to create an example? Once we have a failing test, fixing it will be a lot easier! Thanks! 😸

[subos2008]

I'm finding that with junit results below the first one gets filed under (root) and the second one is interpreted as a class:

<testsuite tests="23" skipped="0" errors="0" failures="0" time="0.456">
<testcase classname="REST adapter Health reporting" name="REST adapter Health reporting" time="0.002">
    </testcase>
<testcase classname="Touch all files touching file nr. 1: /usr/src/app/dist/config.js" name="Touch all files touching file nr. 1: /usr/src/app/dist/config.js" time="0.039">
    </testcase>
</testsuite>

Perhaps it's the presence of a filename?

[pooja2508]

I'm also facing the similar issue for jenkins root package name .

Im using xmlrunner to generate the xml report which looks like this :
testcase classname="FunctionalTest" name="test_1_1_1_1_FunctionalTest" time="1.413"/

In jenkins, this is listed under :
/root/FunctionalTest/

I want to replace the /root Package name with the testcase Class name ie. FunctionalTest.

@shepmaster Could you please suggest ?

[sachingore55]

I'm also facing the similar issue for jenkins root package name .

Im using xmlrunner to generate the xml report which looks like this : testcase classname="FunctionalTest" name="test_1_1_1_1_FunctionalTest" time="1.413"/

In jenkins, this is listed under : /root/FunctionalTest/

I want to replace the /root Package name with the testcase Class name ie. FunctionalTest.

@shepmaster Could you please suggest ?

@pooja2508, Did you find any solution for this?

[xyzesteban]

I'm finding that with junit results below the first one gets filed under (root) and the second one is interpreted as a class:

<testsuite tests="23" skipped="0" errors="0" failures="0" time="0.456">
<testcase classname="REST adapter Health reporting" name="REST adapter Health reporting" time="0.002">
    </testcase>
<testcase classname="Touch all files touching file nr. 1: /usr/src/app/dist/config.js" name="Touch all files touching file nr. 1: /usr/src/app/dist/config.js" time="0.039">
    </testcase>
</testsuite>

Perhaps it's the presence of a filename?

I realize this is an old issue, but I believe this is actually caused by the presence of a dot (.) in the classname property and I also believe this has more to do with the Jenkins JUnit plugin itself rather than specific reporters. The behavior I observed is: 1. Anything BEFORE the first dot is read as a package on Jenkins; 2. Anything AFTER the first dot is interpreted as a class; and 3. If no dot is present, the test gets thrown into a generic (root).

This works very nicely for Java packages with classnames such as com.example.mypackage.javaclass, which I guess is what it's meant for anyway. But not for reporters from other frameworks. In any case, I had to modify my own reporters to meet that Java-esque format.