ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Bailliez <sbaill...@imediation.com>
Subject RE: junit test summary - can I just get one?
Date Tue, 16 Jan 2001 12:21:54 GMT
> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: Tuesday, January 16, 2001 12:36 PM
> To: ant-user@jakarta.apache.org
> Subject: Re: junit test summary - can I just get one?
> 
> C. Kimpton <KimptonC@rabo-bank.com> 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 <bailliez@noos.fr> 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. 

Mime
View raw message