ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Support for JUnit 4?
Date Wed, 22 Feb 2006 14:00:39 GMT
Joe Schmetzer wrote:
> On Wed, 22 February, 2006 11:59 am, Steve Loughran wrote:
>> wrote:
>>>I dont think you concur with me, Steve.
>>>I dont see any advantage using annotations in JUnit4 neither.
>>Having looked at the junit4, I dont see the point in the annotated design.
>>by backing away from having a base class, they have to jump through lots
>>of hoops to make everything work, hoops they have only themselves to
> Without claiming to understand the considerations that went into the
> design of JUnit4, I get the feeling that it is a response to TestNG, which
> relies entirely upon annotations for tagging test methods.

yes. and they jump through hoops to pull it off.

1. the ability to declare the type of exception thrown is good, but 
limited because you can only declare the type, not the content (I often 
check the text, sometimes even the type and text of nested ones)

2. speccing timeouts is good but very brittle. That is per-system metadata.

3. You can declare something that runs before all tests in a class run, 
and afterwards. They could have added that to junit3.8.1's TestCase class.

4. There is some @ignore tag to say "ignore this; Junit4 test runners 
get to count the #of ignored tests. This is where reporting may need 

It is certainly a response to TestNG, with some eclipse hooks in there 
by the look of things. I just dont think they should have followed 
testNG so aggressively.

> I think the whole point of this change is to reduce coupling between test
> methods and the test infrastructure (TestCase, Assert and friends). 

Assert has always been decoupled; you can extend or use it anywhere. 
What they now have in the JAR is two separate Assert classes, 
junit.Assert and org.junit.Assert, with duplicate code. Me, I'd have 
moved everything to the new org.junit.Assert and made junit.Assert a 
facade, not a complete duplicate.

> By
> loosening this coupling, there are more opportunities for testing
> protected methods. But as you note, the test infrastructure must now work
> harder.

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

View raw message