Features

The Testare testing framework offers a rich set of features, most of them targeted for testing distributed java applications.

Rich set of test development concepts

• Test case - a test case is a class that implements test methods and a basic mechanism for test environment creation and clean-up. Test methods are responsible for implementing the test logic. A Testare test case is very close to those defined by any other test framework, such as JUnit, TestNG or JTiger. To create a test case you must extend a class that is defined within the test framework
• Fixture - a fixture is a reusable component that helps managing the test environment required for the test to run. A fixture has two methods:
  • setUp, used to configure a fragment of the test environment as required for the test case to run
  • tearDown, used to clean-up a fragment of the test environment after the executing the test case
  In Testare a fixture has the following particularities:
• The setUp method returns an instance of the fixture itself - as it was modified after its execution. This way, data created by the fixture's setUp method can be accessed by the test case. It is extremely useful when a fixture is executed in remote environments and the test case is executed in a client JVM - a typical in container testing situation. It gives your locally executed test case a chance to access data created by the fixture in the remote environment.
• The tearDown method receives the test result as parameter. This is a useful feature because in some situations this method may have to behave differently depending on whether a test of the test case it decorates has succeeded or failed. For example, if you test a "deleteObject" service, the fixture's tearDown method doesn't have to do anything if the test succeeds, but if the test fails you get a chance to remove the test object from the environment.
A fixture is a reusable test case decorator. To create a fixture you must extend a class that is defined within the test framework
• Global fixture - a global fixture is a component that is used to set up parts of the test execution environment that are required by a set of tests and are generally not modified by the test itself, such as SQL schemas, file system directory structures, etc. Global fixtures are independent, and do not decorate a particular test case. A global fixture can be described as a test suite fixture. To create a global fixture you must extend a class that is defined within the test framework
• Test environment probe - a probe is a reusable test case decorator that helps to investigate if a remote environment - such as a database accessible through an application server data source - has been modified as expected by the test case they decorate. Test environment probes are generally used in conjunction with in container testing. To create a probe you must extend a class that is defined within the test framework
• Test environment guards - guards are reusable test case decorators that make sure the test environment is in a coherent state before and after the test execution. Guards are useful environment integrity check tools. They help detect test cases that leave the environment in an inconsistent state, which may cause other tests to fail. To create a guard you must extend a class that is defined within the test framework
• Automatic execution of test decorators - global fixtures, guards, fixtures and probes are registered with the test case and automatically executed. Developers can this way concentrate on writing tests while the test framework takes care of executing test case and its decorators. The test execution process follows the this choreography:
  1. Global fixtures are identified and stored in a list, in no particular order. The the setUp method of every fixture is executed. If a global fixture setUp method fails, the entire test suite will fail with a meaningful error message
  2. Test cases are identified and stored in a list, in no particular order. For each test case and each execution scenario it implements, and for each test:
  3. For each registered guard, in the order in which guards were registered, the checkPrecondition method is executed. If a precondition check fails, the test execution is dropped and a meaningful error message is returned
  4. For each registered fixture, in the order in which the fixtures were registered, the setUp method is executed. After the execution of the setUp method, the instance of the fixture is replaced with the instance returned by the setup method. If a setUp method fails, the test and the following fixtures are not executed. tearDown methods of executed fixtures will be executed in the reverse order
  5. The test method is executed
  6. For each registered probe, in the order in which the probes were registered, the executeProbe method is executed. If a problem fails, the test will fail with a meaningful error message
  7. For each registered fixture, in the reverse order in which the fixtures were registered, the tearDown method is executed. If a tearDown method fails, the test will fail with a meaningful error message
  8. For each registered guard, in the reverse order in which the guards were registered, the checkPostcondition method is executed. If a post condition fails, the test will fail with a meaningful error message
  9. for each global fixture, the tearDown method is executed

Execution scenarios

- instruct the test framework to automatically execute tests and test case decorators in a particular execution environment - such as an EJB container - by just implementing a marker interface on a test case or on a test case decorator. This is how TESTARE implements the in container testing concept. Execution scenarios help offering the following functionality:

• floating scenario - enables test decorators to be executed in the same execution environment as the test case itself. This can prove handy when using in container testing and a test decorator - a fixture, for example - must be executed in exactly the same environment as the test case it decorates.
• EJB testing - implements in container testing for EJBs, by executing a test case within an EJB container. Different EJB scenarios are provided to simulate the different transactional settings an EJB container supports

Flexible integration and reporting capabilities

• An ant interface is offered by default
• It is possible to develop and plug in custom test case finders
• It is possible to develop and plug in custom test result reporting tools

The project's white paper contains a more detailed list of features and indications on how to use them. There is also a list of answered questions about this testing framework.