ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Junut4 (was Re: svn commit: r381780 - in /ant/core/trunk: WHATSNEW docs/manual/OptionalTasks/junit.html src/main/org/apache/tools/ant/taskdefs/optional/junit/ src/main/org/apache/tools/ant/taskdefs/optional/junit/
Date Wed, 01 Mar 2006 13:05:42 GMT
Martijn Kruithof wrote:
> Isn't this a bit premature, junit 4 isn't even "out" yet. 

shipped last week. Gump is still recovering.

>Furthermore I 
> thought junit 4 would get rid of the distinction between failure and 
> error, wouldn't we want to remain in-line with this new junit behaviour 
> when running junit 4 testcases in an junit 4 environment?

Just because junit4 wants that behaviour does not mean we need to follow.

On this topic, Jon Skeet is setting up the logistics for a conference 
call between the junit people and the ant team, primarily on the future 
of <junit>

Being a conference call, it would probably overload if everyone joined 
in, but at the same time, I dont want to keep it a secret from 
interested parties. We'll be discussing where we are with junit, what's 
wrong with it and where do we go for junit4 --which may mean the junit 
team will take over ownership of a junit4 task.

There was some discussion of junit4 implications in the ant-user mail 
list, but since then Jesse has just fixed two main failings of <junit> 
-classpath setup and (I believe) direct support for junit4.

We need to look at where we stand with this, whether it is enough, and 
what else should be done. Here is my opinion

What does Ant's junit task does well:

-integrates testing with the build
-runs well in a new JVM
-segues into reporting with junitreport (a bit fiddly; could be integrated)
-provides some minimal output as you go along, one that lets you infer 
state from the logs
-distinguish (possibly needlessly) errors and failures

What it does badly
  -installation. <junit> is the first time most people encounter ant lib 
setup grief.
  -forked JVM classpath setup. you need junit.jar, xerces on the CP.

What it doesnt do
  -drop abstract classes from the fileset (would be very nice)
  -only try and run classes that extend TestCase or are annotated as 
test methods (would be nice, no?)

what third party stuff adds
  -choreograph deploy+liveness+test+undeploy (cactus does that)
  -distribute. What if I want to test on a different machine? (I think 
JBoss' JRunner does this, and my distributed JUnit component for 
smartfrog is aimed at this problem)

I dont think the Ant task should try and do the third party things, but 
it must enable things like cactus. Furthermore, the stuff in "does 
badly" and "doesnt do" should be addressed, while retaining the things 
that work today.

There are some other wish-list items I'd like for junit, that I haven't 
covered. a medium priority spare time activity for me at work is 
distributed junit: deploying tests on hosts 1-10, collecting results on 
host 11, trying to present them in a way that makes sense. The GridUnit 
project does some of this; they share my code for serializable test 
results. I'd really like junit's results to be serializable out the box, 
and junit4 results to be compatible, but I can work around this, after 
all, exceptions don't serialize and I have to strip-mine meaningful data 
from them.

So: open discussion. What would people want from a <junit4> task?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message