ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject Re: Junut4
Date Thu, 02 Mar 2006 20:51:31 GMT
Kev Jackson wrote:
> That would certainly be optimal.  (+1 for seperate task)

If others agree, should the existing 4 support in <junit> be reverted? 
It can be considered a proof of concept in its current state. My main 
concern is that making it a separate task would require people to change 
their build scripts gratuitously. I do think that whatever form the 
support takes, it should be in the standard Ant distro.

I believe the changes which might require a change to the <junit> task 
signature, associated interfaces, or result XML format are:

1. Reporting of ignored tests, which would require an optional extension 
to, or alternative to, the JUnitResultFormatter interface for custom 
formatters, as well as impl of that extension / alternative in the 
shipped formatters. Assuming most people use the standard formatters, 
they don't need to touch their script. The XML format for test results 
(and its default stylesheet) might also need extensions.

2. Timeout failures; similar to #1, though this could probably be 
skipped (just treat as a general failure with appropriate message). 
Seems that 4's RunListener anyway doesn't report it specially?

3. Test failed to throw expected exception; similar to #2.

4. Display only a "failure" count and no "error" count (if this is in 
fact desirable - does not appear to be consensus); similar to #1.

5. I thought there was support for named "categories" of tests in 4, but 
I can't now find it - maybe it was dropped for 4.0, or maybe I was 
thinking of TestNG?

6. Sorting of tests (e.g. by last fail time) - not clear to me if this 
is something an Ant task should address.

7. Use of Filter, e.g. to run one test method only. But this is 
desirable for JUnit 3 anyway (see Bugzilla).

Other changes which probably don't imply any signature change:

1. Handling of StoppedByUserException (not sure when this is thrown).

> With this addition to Ant 1.7 code base, we now have code that relies on 
> jdk1.5 to build correctly (or will it build on <1.4?).

It shouldn't require anything above 1.2 to build; everything in 
junit-4.0.jar (not much) is accessed via reflection. JDK 1.5 is only 
required to run if you actually have junit-4.0.jar in your test's CP 
(and not junit-3.8.1.jar first); or you want to run 4-based tests.

> If this is the 
> case, is there perhaps a case for moving some of the codebase forward 
> from pre 1.2?  I know that these changes are only in one of the tasks 
> (and an optional one at that), but I think it's time to look at 
> deprecating 1.1.8 support and at least move the core up to 1.2 standard 
> (with Collections etc).

Don't we already presume at least 1.2 to compile (and run) for Ant 1.6+ 
generally? There's no reason not to use Collections in Ant today, except 
for places where we have a historical API mentioning Vector or Hashtable 
that can't be changed compatibly.


--  x22801*i)%2B1

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

View raw message