ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject Re: <junit> and junit4 (long)
Date Thu, 01 Jun 2006 19:47:11 GMT
Steve Loughran wrote:
>  -setting up the xml listener (needs xml parser on the path)

Are enough people still using JDK 1.2/3 that this remains a common 
problem? Certainly irrelevant for a junit4 task which can assume JAXP.

>  -people don't get their selection patterns right, and we try and run 
> things that arent tests. We could do a check here for 3.x, but not for 
> junit 4.

Might be possible even in junit4 - just check for classes with no @Test 
annotations, perhaps.

>  -People get extra burned when their pattern is **/Test* and they have a 
> nested inner class, because of course that TestSomething$Inner.class 
> matches the pattern

Rather than adding an ad-hoc attribute for this problem, I would suggest 
just making sure we don't run non-tests. That would automatically take 
care of this problem. (Unless your nested class is really a static 
TestCase, in which case maybe you really wanted to run it!) And/or print 
a warning if any *$*.class matches the pattern, telling people to use


if that is what they meant.

>  -not well integrated with logging APIs. we get the text as printed to 
> stdout, but lose the full log metadata. If we had something behind 
> commons-logging we could capture logs as data rather than as stdout 
> messages.

Is this really something that should be dealt with by an Ant task? Seems 
to me that the proper home for this is a non-Ant-specific library to be 
used by tests that need logging capture. You can capture to a file or to 
a memory buffer which is included in a failure message if there is one.

> (1) I would [like to help], with that caveat about no free time.

I might be able to as well.


--  x22801*i%29%2B1

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

View raw message