Thanks, Kristian. This is indeed helpful. My takeaway is that our JUnit
primer should recommend something like this as the pattern if developers
need to move the setup()/teardown() brackets outside a cluster of tests.
Regards,
-Rick
Kristian Waagan wrote:
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
