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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
