Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: v_borchert@despammed.com (Volker Borchert)
Newsgroups: comp.lang.java.programmer
Subject: Re: Testing the functionality of sub classes
Date: 19 Aug 2017 21:15:24 GMT
Organization: Private site at Eddersheim, Germany
Lines: 37
Distribution: world
Message-ID: <ona9pc$5i6$1@Gaia.teknon.de>
References: <87fucnh2wu.fsf@munus.decebal.nl> <subclasses-20170819193036@ram.dialup.fu-berlin.de> <87y3qffim5.fsf@munus.decebal.nl>
X-Trace: individual.net Ht8IFG5qNqKZxlhyi9eMRgnpR6buQsp+PYJzREUcbrwaVpCvSu
Cancel-Lock: sha1:pD68gBcugmqbKJFNszHXGtKjufc=
Xref: csiph.com comp.lang.java.programmer:37302

Cecil Westerhof wrote:

> >>I have a class that is extended in several sub classes. Is there a way
> >>to let the tests for the super class to be run on all sub classes?
> >
> 
> For the test of the super class AbstractSQL, I have written a test
> class SQLTest in which I implemented all the tests with the sub class
> SQLite3. But there will be more. At the moment there are only two sub
> classes (the other is SQLH2) and for two classes it is not to much
> work. But I expect it to become a little more. So I would like to
> write the test class so that all the tests are done for all the sub
> classes.

Are you talking JUnit? Then have an abstract class annotated as
@RunWith(Suite.class) and @Suite.SuiteClasses({ <class literals
for all your concrete test classes> }) , containing most @Test
methods and declaring a single abstract method that provides
the concrete implementation object to test. For each concrete
class-to-test, you'll need a concrete test class deriving from
the above, listed in its @Suite.SuiteClasses, and implementing
the single abstract method. This derived test class may contain
additional @Test methods applicable to only this concrete
class-to-test.

<opinion>
This approach is not fullyautomagic, but simple enough to write
and, more important, easy enough to understand for the innocent
reader. Any tricks with javadoc parsing or JAR enumeration are
too brittle, too obfuscated, and too difficult to justify the
minimal savings of avoiding those derived test classes.
</opinion>

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>