RSE Test Framework

## What's The Point?

You're an eclipse developer and you've become test-infected. You've made the leap and bought into the JUnit and XP philosophy of writing your testcases first and running them after every significant change you make. You just wish you had three things: (1) an easy way to repeatedly run them while debugging (2) a way to run several times without starting up and taking down a workbench each time and (3) an easy way for others to use them to verify that their work didn't impact yours.

The RSE Test Framework is for you.

The framework provides a means for presenting and running your JUnit tests inside a runtime workbench without using the PDE JUnit driver. This lets you to ship test suites that other teams can run for either verification, testing, or diagnostic purposes. The framework exploits the JUnit unit test framework and provides much of the function that a test runner from that framework provides inside a bona fide eclipse view.

It provides a framework in which your tests are easily repeatable and allows function to be tested off the main UI thread.

### What Does This Do That JUnit Doesn't?

The answer is "not much" -- yet.

The framework performs essentially the same function as a JUnit test runner, but does it in an eclipse and SWT compatible way. It provides a means for registering tests with a workbench so that they can easily be run repetitively during debug sessions and during driver build verification tests (aka sniff tests).

Results are captured and presented in a text pane and can be copied from there to a document of your choice, such as a bug report.

"But," you say, "I can do all this with JUnit and PDE!" Of course, but PDE doesn't provide you with a way of delivering your test suites in a build. PDE's JUnit support allows you to run tests from a development workbench in a runtime workbench. The framework, on the other hand, allows you to run them directly in a standard build or in a standard build that is being run as a runtime workbench under control of your development workbench.

With the addition of some support for "test scripts" (see Future Items) semi-automated UI testing should become much easier.

### How This Might Be Used

There are two different places the framework can help you. One is in running and tracking the tests on your own. The other is automating test suites that others can run.

#### Unit Test

Since the framework has its origins in JUnit, it should be no suprise that it can be used for unit testing -- either of the tests themselves or of the function being tested. You can easily construct a new plugin to point at or contain your JUnit Test Suites, start up a runtime workbench under debug, run the tests, and if things go wrong set breakpoints and replace code in either the test suite or in the tested function. You can use the framework as your test driver.

#### Various post development tests

All of these test phases use tests developed by you or your testing team. Some of these can be fully automated under the framework, particularly for sniff tests and regression tests. When the scripting facility becomes available, you should be able to semi-automate tests that require UI verification.