diff options
Diffstat (limited to 'rse/tests/org.eclipse.rse.tests.framework/html/purpose.html')
| -rw-r--r-- | rse/tests/org.eclipse.rse.tests.framework/html/purpose.html | 1 |
1 files changed, 0 insertions, 1 deletions
diff --git a/rse/tests/org.eclipse.rse.tests.framework/html/purpose.html b/rse/tests/org.eclipse.rse.tests.framework/html/purpose.html deleted file mode 100644 index 1270e2eaa..000000000 --- a/rse/tests/org.eclipse.rse.tests.framework/html/purpose.html +++ /dev/null @@ -1 +0,0 @@ -<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>RSE Test Framework</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css"/>
<link rel="stylesheet" type="text/css" href="../book.css"/>
</head>
<body>
<h2>What's The Point?</h2>
<p>You're an eclipse developer and you've become <em>test-infected</em>.
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.</p>
<p>The <strong>RSE Test Framework</strong> is for you.</p>
<p>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 <em>bona fide</em>
eclipse view.</p>
<p>It provides a framework in which your tests are easily repeatable and allows
function to be tested off the main UI thread.</p>
<h3>What Does This Do That JUnit Doesn't?</h3>
<p>The answer is "not much" -- yet.</p>
<p>The ATF 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 <em>sniff tests</em>).</p>
<p>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.</p>
<p>"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.</p>
<p>With the addition of some support for "test scripts"
(see <a href="futures.html">Future Items</a>) semi-automated UI testing should become
much easier.</p>
<h3>How This Might Be Used</h3>
<p>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.</p>
<h4>Unit Test</h4>
<p>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.</p>
<h4>Various post development tests</h4>
<p>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.</p>
</body>
</html>
\ No newline at end of file |