[jboss-dev] JUnit should not attempt to instantiate/run unit test classes defined as abstract, thoughts?

[Brian Stansberry]

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,

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com