ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 24106] - Suites are not reported correctly in JUnitReport
Date Sat, 16 Feb 2008 02:09:47 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=24106>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=24106





------- Additional Comments From dan@fabulich.com  2008-02-15 18:09 -------
FYI, I spent some time working on this today, not really because I need it, but
because people keep complaining to me that Maven Surefire is broken because it's
incompatible with JUnitReport.  :-)

http://www.nabble.com/Test-Suites,-Ant,-Surefire,-and-JunitReport-td15076378.html

Ant 1.6 (I think?) introduced a helpful attribute on all of its <testcase>
classes to include the class name of the class on every <testcase> element:

     <testsuite name="com.mycompany.MyTestSuite" failures="0" errors="0"
tests="4" time="0.031">
       <properties><!-- ... --></properties
       <testcase name="test1a" time="0.0" classname="com.mycompany.Test1" />
       <testcase name="test1b" time="0.0" classname="com.mycompany.Test1" />
       <testcase name="test2a" time="0.0" classname="com.mycompany.Test2" />
       <testcase name="test2b" time="0.0" classname="com.mycompany.Test2" />
       <testcase name="test3a" time="0.0" classname="com.mycompany.Test3" />
       <testcase name="test3b" time="0.0" classname="com.mycompany.Test3" />
     </testsuite>

This is good, because it allows you to figure out which class the method really
belongs to.  This is what both Surefire and TestNG output when they generate
JUnit-like results.  Unfortunately, nobody honors the "classname" attribute,
including Ant 1.7's JunitReport task!

Further on in the thread linked above, Steve suggested I try my hand at updating
the XSLT.  I assert that fixing the XSLT without changing Ant is/would be
fricking impossible.  We could maybe handle it if the XML were organized like this:

     <testsuite name="com.mycompany.MyTestSuite" failures="0" errors="0"
tests="4" time="0.031">
       <properties><!-- ... --></properties>
       <package name="com.mycompany">
         <class name="Test1" />
           <testcase name="test1a" time="0.0"/>
           <testcase name="test1b" time="0.0"/>
         </class>
         <class name="Test2" />
           <testcase name="test2a" time="0.0"/>
           <testcase name="test2b" time="0.0"/>
         </class>
         <class name="Test3" />
           <testcase name="test3a" time="0.0"/>
           <testcase name="test3b" time="0.0"/>
         </class>
       </package>
     </testsuite>

But getting from the first schema into the second schema is brutally challenging
in XSLT 1.0 (the version with which we'd have to remain compatible).  

The hardest part is trying to reorganize the test cases into classes, without
the use of XSLT 1.1 node-sets.  You've got to loop through the test cases,
recognize classes that you've already seen, and group them together when they match.

Even just splitting the class string into its package, while possible, is really
annoying in XSLT; right now Ant does it at the suite level in Java in
XMLResultAggregator.

If an XSLT masochist, er, I mean WIZARD wants to take a crack at this problem,
I'm sure it'd be appreciated.  junit-noframes.xsl is only a few hundred lines
long; how bad could it be? ;-)

I suppose I could put together a patch in XMLResultAggregator, but then it's not
entirely clear whether my goal should be to remain backwards compatible with the
existing XSLT that's out there (presumably by splitting <testsuite> elements up
into multiple <testsuite> elements in the TESTS-TestSuites.xml file) or what.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message