db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Features of the JUnit test execution harness
Date Thu, 26 Jan 2006 10:52:41 GMT
Rick Hillegas wrote:
>>
>> Kristian Waagan wrote:
>>
>>
>>>
>>> 2) Should we support setting up a shared test fixture for a set of 
>>> tests?
>>>
>>> This is a common issue with JUnit, and there are mechanisms to handle 
>>> it. For instance, we could let tests that require this to wrap itself 
>>> in a TestSetup instance (as described in the JUNit FAQ). Letting 
>>> DerbyJUnitTest extend TestSetup is another solution, but it might 
>>> have unwanted side-effects.
>>
>>
> Hi Kristian,
> 
> I'm afraid I don't understand the issues here. I suspect your JUnit 
> experience is much deeper than mine. What is the advantage to having 
> DerbyJUnitTest extend TestSetup vs TestCase? It's hard to tell from the 
> FAQ. TestCase provides setup() and teardown() brackets like TestSetup. 
> In addition, TestCase provides the assertion machinery. What unwanted 
> side-effects do you have in mind?
> 
> Thanks,
> -Rick

Hello Rick,

Your concern is valid. Having our Derby JUnit superclass 
(DerbyJUnitTest) extend TestSetup is not a good idea.

The proper way to use it is as described in the FAQ, or to create a 
separate TestSetup subclass. Just to make sure we are on the same track, 
the reason for using TestSetup is to provide the test with a one-time 
setUp() and a one-time tearDown() method. If your JUnit class has 3 test 
methods, this sequence would be run (ordering of the test methods may 
not be fixed):

TestSetup.setUp()
     TestCase.setUp
         TestCase.testMethodA()
     TestCase.tearDown()
     TestCase.setUp
         TestCase.testMethodB()
     TestCase.tearDown()
     TestCase.setUp
         TestCase.testMethodC()
     TestCase.tearDown()
TestSetup.tearDown()

My concern is that many of our tests do not want to do a complete setUp 
and tearDown for each test, as this can cause the runtime for the test 
to be too long. By using the one-time methods, we can create a common 
setup for all the tests in the suite.

To illustrate the two ways to use TestSetup, consider the following 
suite() methods:

 From the JUnit FAQ, the following example demonstrate how to use 
TestSetup without creating a separate class.

public static Test suite() {

         TestSuite suite = new TestSuite();

         suite.addTest(SomeTest.suite());
         suite.addTest(AnotherTest.suite());

         TestSetup wrapper = new TestSetup(suite) {

             protected void setUp() {
                 oneTimeSetUp();
             }

             protected void tearDown() {
                 oneTimeTearDown();
             }
         };

         return wrapper;
     }

     public static void oneTimeSetUp() {
         // one-time initialization code
     }

     public static void oneTimeTearDown() {
         // one-time cleanup code
     }


The other way.

public static Test suite() {
     // Add all test methods in the class.
     TestSuite suite = new TestSuite(MyJUnitTestClass.class);
     // Create a new TestSetup subclass for our test.
     // This would have a setUp() and a tearDown() method, and possibly
     // several constructors and/or methods to control the setup to be
     // created.
     return new MyJUnitTestClassSetup(suite);
}

For the example above, there are lots of variants. We can return a suite 
that runs all tests in the test with X different setups, and 
additionally run a subset of the tests with a special setup. To do this, 
we must either create several TestSetup subclasses, or parameterize the 
TestSetup subclass.



Did this make any more sense?



--
Kristian

Mime
View raw message