Hi,
JUNIT encourages developers to write setUp()/tearDown() methods for test
initialization/finalization. These methods are executed for each test
method. TCK test classes follow this approach initializing the database
in setUp(), relatively deleting persistent instances in tearDown().
There are many TCK test classes having methods which query the database
without changing its state, e.g. query test classes. As JUNIT executes
setUp()/tearDown() for each test method, those kind of classes have a
performance overhead wrt database initialization/finalization which is
not necessary: It would be sufficient to initialize/finalize the
database only once for all test methods.
Below you find an investigation if this idea can be combined with TCK
and JUNIT.
JUNIT provides a class for this purpose (TestSetup) providing hooks
setUp()/tearDown(). Instances of this class may be constructed passing a
test suite. Test suites are objects holding a number of test methods. In
contrast to usual test classes, setUp()/tearDown() hooks of class
TestSetup are executed only once for all test methods added to test suites.
There are several approaches of how to incorporate this concept into the
TCK:
1) The test runner may wrap test suites for each test class into
instances of TestSetup executing these instance instead of test suites.
2) Currently, TCK test classes inherit from class TestCase. This may be
changed in order to inherit from class TestSetup instead.
As a consequence of 2), all TCK test classes would execute
setUp()/tearDown() only once. This is not an option because the hooks
must be executed for tests methods changing the database.
3) Option 2) may be improved by the fact that only those test classes
inherit from TestSetup which have test methods not changing the database.
Unfortunately, none of the options above work for the TCK: Creating test
suite instances, JUNIT creates a test class instance for each test
method. All TCK test classes hold test initialization state in instance
variables. This means that setUp()/tearDown() hooks must be executed for
each test method.
4) In conjunction with 3) or 1), it might be possible to create a
subclass instance of TestSuite in test runner. This subclass would hold
the same test class instances for all methods of the same test class.
It seems, that only option 4) might have the desired result. However, I
have not investigated in detail if it is possible to implement this option.
For this reason, I propose to leave the implementation as is if there
are not better ideas to accomplish the goals above.
Regards,
Michael
--
-------------------------------------------------------------------
Michael Watzek [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
