mirror of
https://github.com/eclipse-cdt/cdt
synced 2025-07-05 16:15:25 +02:00
1 line
No EOL
4 KiB
HTML
1 line
No EOL
4 KiB
HTML
<?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 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 <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>
|