I see you noticed testsuite failures from your abstract class :)

Oh, sorry; I saw that on trunk over the weekend and tweaked the cluster-excludes filter to ensure the testsuite didn't try to run stuff in that package (which was a minor tweak I needed to make anyway). I didn't think about how you were porting this all over the place; should have given you a heads-up. My bad. :(

Galder Zamarreno wrote: > Hi, > > Let's say you define an abstract unit test class which is contains > test methods that are run for concrete implementations, i.e.: > > class abstract MyAbstractTestCase > { > void test000(){} > void test001(){} > } > > class YourConcreteTestCase extends MyAbstractTestCase > {} > > class HisConcreteTestCase extends MyAbstractTestCase > {} > > If you have a filter to run tests ending in *TestCase, JUnit will try > to run all 3 classes: MyAbstractTestCase, YourConcreteTestCase, > HisConcreteTestCase, i.e. > > test000 for MyAbstractTestCase > test001 for MyAbstractTestCase > > test000 for YourConcreteTestCase > test001 for YourConcreteTestCase > > test000 for HisConcreteTestCase > test001 for HisConcreteTestCase > > An abstract class is, amongst other things, a class that can't be > instantiated. Why does JUnit attempt to (doing something funky, that's > for sure) go against the Java rules and try to execute an abstract > unit test class? I'd expect YourConcreteTestCase and > HisConcreteTestCase to be executed as they're concrete implementations. > > Of couse, this can easily be avoided by renaming the Abstract class to > something that does not end in *TestCase, but why should I? I defined > it as abstract, do not instantiate it :) > > Cheers,

On Wed, 2007-11-21 at 16:31 +0100, Galder Zamarreno wrote: > <rant> > I don't see why I should be doing it though. IMO, JUnit is wrong, not me :). > </rant> I think you'll find it is the ant plugin rather than junit. http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant... Junit just tries to do what it's told to do.