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