> -----Original Message-----
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 16, 2001 12:36 PM
> To: [EMAIL PROTECTED]
> Subject: Re: junit test summary - can I just get one?
>
> C. Kimpton <[EMAIL PROTECTED]> wrote:
>
> > Ant can find my tests (assuming I name them consistently) but it
> > gives a test summary per class - is there a way/plans for just
> > getting one summary?
>
> Plans? Yes. Getting to implement them? Unfortunately no.
It's on its way. :)
> Stephane Bailliez <[EMAIL PROTECTED]> has taken over part of it (and I
> should say "thank you" a lot more often) and I'm not sure what his
> status is. He has added the ability to specify add an output directory
> in 1.3alpha already.
No problem for the thank you, you cannot do everything in Ant yourself, you already did a tremendous job.
> > I guess this would effectively mean writing a generic test within
> > ant that looks for/uses the list of tests classes found as one large
> > suite. Then, when junit runs that, it will give one summary for the
> > whole suite.
> No, I think we should rethink who should be responsible for writing
> the logging information for a batchtest and not scatter this between
> the testrunner, the testelement and the logger. As far as I can tell
> Stephane is on the right track here.
I did some refactoring and thought a little bit about it, but this is problematic.
I personally would like to avoid having 2 different runners.
- Running in the Ant VM doesnt't have much sense for me. You pay the risk of crashing/hanging your build.
This also add some extra code and complexity. No point supporting something that doesn't have much sense.
If we rely on running the test in another VM, the runner JVM should be listening for TestResult (via sockets ?).
If the listener is outside the testcase vm, this also avoid generating empty results when the test is canceled.
Doing this might imply a lot of change and some features I would like to add will intercept with the one in the todo list in JUnit, so I will wait a little bit for it, and see if I can also participate to JUnit dev.
However: As of now I wrote a simple test aggregator that will aggregate all xml tests into a single xml file so that you can apply some xsl style after that:
something like:
<junit ..>
....
<aggregate todir="./xmloutput" style="frames">
<fileset dir="./xmloutput">
<include name="**/TEST-*.xml"/>
</fileset>
</aggregate>
</junit>
This will generate a complete file TESTS-TestSuites.xml, with the style "frames", several stylesheets will be applied to it so that the result will be a complete report in a Javadoc-like way (summary, package summary, testcase, etc...), with the style "noframes" it will generates all the report in a single page (via an xsl also).
I also did some minor change in the dtd (removed the time unit so that all the stats can be done in xsl) and separated the package from the name. (It's hell to do this in xsl if you want also to sort on both package and classname)
The xsls are the only thing to be done, they are quite complex but I have already some cool prototypes.
I expect to do it before the end of this month. Sorry for this delay but expect cool reports :)
--
St�phane Bailliez
Software Engineer, Paris - France
iMediation - http://www.imediation.com
Disclaimer: All the opinions expressed above are mine and not those from my company.
