I think there's a lot of value in having a suite-level setup mechanism,
I totally agree that doing setup for each test can be overkill and I am
often finding ways to work around it.
David
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
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
