Jeté uses extensions to the JUnit framework TestCase class to perform the configured tests. In their simplest form, these test cases simply have a list of test actions. All test cases do is run through this list of test actions and runs the action.
A system test is basically a collection of these test cases. There are some nuances to how the system test defines these test cases, but the basic idea stands.
Test Case Hierarchy
The system test cases all extend the JUnit TestCase.
The primary test case for the system test is BaseActionTestCase. This test case has a collection of setup actions and teardown actions (these are the exact same actions used to define test case behavior) as well as a collection of test actions. The base test case functions as such:
- JUnit invokes the test case as normal (through a TestRunner, e.g. Ant)
- JUnit runs the BaseActionTestCase setup method, which runs each action in the collection of setup actions collection.
- JUnit runs the extended test case (for example: ActionTestCase) runTest method, which retrieves the collection of test actions and runs each.
- JUnit runs the BaseActionTestCase teardon method, which runs the action in the collection of teardown actions collection.
This is a simple implementation of the BaseActionTestCase. This test simply defines a list of actions that are run when the test is invoked.
See Sample ActionTestCase
This test runs multiple test cases (e.g. ActionTestCase), allowing them to be configured together in such a way as to permit thread pooling. If a thread pool is defined, these tests are run in parrallel, otherwise serial.
This allows testcases in another file to be executed. The main benefit of this test case is that the Spring configuration file doesn't get loaded into memory until this test is called, and the Spring context objects can be removed when completed. This provides some capacity scale well when thousands of tests (and corresponding objects) are system tested. This test extends the MultiTestCase.
See Sample ContextFileTestCase