mirrors/cdt
1
0
Fork 0
mirror of https://github.com/eclipse-cdt/cdt synced 2025-07-04 07:35:24 +02:00
Code Issues Wiki Activity

[174770][doc] removing  , adding missing closing tags, fixing nesting and ids.

Browse source
This commit is contained in:
David Dykstal 2007-02-22 21:15:24 +00:00
parent 2cbfd023fe
commit 026349d699
18 changed files with 42 additions and 46 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
rse/doc/org.eclipse.dstore.doc.isv/guide/Artifacts.html
View file

@ -17,7 +17,7 @@
<li><A href="#dataelement">DataElement</A></li>
<li><A href="#miner">Miner</A></li>
</ul>
<p>All the classes and interfaces mentioned here are defined in the <samp>org.eclipse.dstore.core</samp> plugin.
<p>All the classes and interfaces mentioned here are defined in the <samp>org.eclipse.dstore.core</samp> plugin.</p>
<h2><A name="clientconnection">Client Connection</A></h2>
<p>

3
rse/doc/org.eclipse.dstore.doc.isv/guide/Communications.html
View file

@ -78,6 +78,7 @@ over the network. For its handlers, the local DataStore uses a <b>Client Update
<p>
In the above dialog, the path of commands to the tools is shown with solid lines, while the path of data to client is shown with dotted lines.
</p>
<ol>
<li>
@ -99,7 +100,6 @@ The Client Update Handler gets the data from the queue and sends out a domain no
A domain listener for the RSE subsystem receives the notification and then uses the result data to update the UI.
</li>
</ol>
</p>
<h2>Client/Server DataStore</h2>
<p>
@ -154,6 +154,5 @@ The Client Update Handler gets the data from the queue and sends out a domain no
A domain listener for the RSE subsystem receives the notification and then uses the result data to update the UI.
</li>
</ol>
</p>
</body>
</html>

6
rse/doc/org.eclipse.dstore.doc.isv/guide/DataElements.html
View file

@ -16,6 +16,7 @@ that have attributes and may contain other DataElements. The attributes of a Da
strings. A particular attribute is retrieved by calling <code>getAttribute(</code><i>attribute index</i><code>)</code>.
A particular attribute is set by calling <code>setAttribute(</code><i>attribute index</i><code>, </code><i>attribute value</i><code>)</code>.
The attribute indices that can be used are as follows:
</p>
<table>
<tr><td><b>Attribute</b></td><td><b>Description</b></td></tr>
<tr><td><code>A_TYPE</code></td><td>Attribute indicating the type of object. The type can be used to indicate the type of an instance of data, a descriptor, a relationship or a commnad.</td></tr>
@ -23,9 +24,8 @@ The attribute indices that can be used are as follows:
<tr><td><code>A_VALUE</code></td><td>Attribute indicating the more information about that object</td></tr>
<tr><td><code>A_SOURCE</code></td><td>Attribute indicating source information about an object, if applicable</td></tr>
<tr><td><code>A_REF_TYPE</code></td><td>Attribute indicating whether the object is a normal object ("value"), a spirit ("spirit"), or a reference to another DataElement ("reference"). In the DataStore, a reference to another DataElement is represented with a DataElement. For more information on spirit elements, see <a href="MemoryManagement.html">Memory Management in DataStore</a> </td></tr>
<tr><td><code>A_ID</code></td><td>The unique ID of a DataElement.</td></tr>.
<tr><td><code>A_ID</code></td><td>The unique ID of a DataElement.</td></tr>
</table>
</p>
<p>
Rather than representing different types of objects as different classes, the type attribute of a DataElement
indicates its type. There are two general categories of DataElements. There are schema elements, <A href="#descriptors">descriptors</a>, and instances of
@ -196,7 +196,7 @@ contributed by a miner are expected to be handled by the contributing miner. Wh
a miner creates a new command descriptor, the <code>A_SOURCE</code> attribute indicates
to the DataStore that an instance of that command should be routed to that miner when
it's issued.
<p>
</p>
<p>
See the section, <a href="Miners.html">Miners</a> to find out how miners contribute schemas

8
rse/doc/org.eclipse.rse.doc.isv/guide/plugin/subsystem.html
View file

@ -197,10 +197,10 @@ following summarizes the minimum set of classes you will be creating in order to
in the <samp>startup()</samp> method of your plugin class, add code to instantiate the class and register the object with
the platform adapter manager, once for each class in your resource model. For example:
<br><samp>
&nbsp;&nbsp;MyAdapterFactory factory = new MyAdapterFactory(); // extends AbstractSystemRemoteAdapterFactory<br>
&nbsp;&nbsp;IAdapterManager manager = Platform.getAdapterManager();<br>
&nbsp;&nbsp;manager.registerAdapters(factory, MyModelObject1.class);<br>
&nbsp;&nbsp;manager.registerAdapters(factory, MyModelObject2.class);<br>
MyAdapterFactory factory = new MyAdapterFactory(); // extends AbstractSystemRemoteAdapterFactory<br>
IAdapterManager manager = Platform.getAdapterManager();<br>
manager.registerAdapters(factory, MyModelObject1.class);<br>
manager.registerAdapters(factory, MyModelObject2.class);<br>
</samp>
</li>
<li>If your filter string from step 5 is complicated enough, you will probably find the

4
rse/doc/org.eclipse.rse.doc.user/concepts/cbegin.html
View file

@ -42,9 +42,7 @@ filter pools, and filter pool references</a>, which list a set of
folders and files from your server in the Remote Systems view. </p>
<p>You can use the Remote System Explorer to access files on many
kinds
of servers, such as Linux, UNIX, Windows, or your local workstation. If
you have the appropriate IBM products installed you can also connect to
iSeries and zSeries servers.&nbsp; See the
of servers, such as Linux, UNIX, Windows, or your local workstation. See the
links below for information on how to connect to these other kinds of
servers.</p>
</div>

4
rse/doc/org.eclipse.rse.doc.user/concepts/cfilters.html
View file

@ -29,9 +29,9 @@ these tasks on these remote resources by using <i>filters</i> that
show these resources at your workstation.<br/>
</div>
<p>The Remote System Explorer perspective is designed to allow you to
manipulate the resources directly on the remote system.&nbsp; The
manipulate the resources directly on the remote system. The
actions that are available depend on the type of system you are
connecting to and the way the resource is recognized.&nbsp; For
connecting to and the way the resource is recognized. For
example, your selections can define
a filter string to find all files that match *.c in a particular
directory. </p>

2
rse/doc/org.eclipse.rse.doc.user/concepts/cprofile.html
View file

@ -65,7 +65,7 @@ but a teammate can make that profile active in his or her workspace.
You will
see the profiles you or your teammates have made inactive in the Team
view when you perform a synchronization with the repository in which
the profiles are stored.&nbsp; See topics in the help contents and
the profiles are stored. See topics in the help contents and
links
below about team support for more information on profiles and shared
data.</div>

6
rse/doc/org.eclipse.rse.doc.user/concepts/cremcompile.html
View file

@ -14,7 +14,7 @@
<h1 class="topictitle1">Compiling Programs</h1>
<div>
<p>You can run a compile command on a server from the Remote System
Explorer perspective.&nbsp; When you compile, the workbench determines
Explorer perspective. When you compile, the workbench determines
the source type of the file, and then runs
the last used compile command for that type. However, you can always
change
@ -35,7 +35,7 @@ specify for that workspace.</p>
<p>A compile command is always associated with a particular source
type. It consists of an identifier and a command string that will be
run on the
server.&nbsp; Each profile in the Remote System Explorer has a set of
server. Each profile in the Remote System Explorer has a set of
source member types,
and each source type has a set of compile commands associated with
them. You
@ -43,7 +43,7 @@ can add source types to a profile and add compile commands to a source
type.</p>
<p>IBM supplies a number
of default compile commands for common file types and you can also add
your own.&nbsp; Since compile commands are owned by a profile they can
your own. Since compile commands are owned by a profile they can
be shared using team support.</p>
<p>See the related topics below for more information.</p>
</div>

6
rse/doc/org.eclipse.rse.doc.user/concepts/cteam.html
View file

@ -13,7 +13,7 @@
<div>
<p>The team support model works with shared repositories that store
version-managed resources on servers that are accessible to the entire team. Usually
you would share the folders and files of an Eclipse project.&nbsp; Each
you would share the folders and files of an Eclipse project. Each
team member sends their changes to the repository, and receives changes
that
were made by a team member from the repository. While the Remote System
@ -44,8 +44,8 @@ Remote System
Explorer resources from your team, including their profiles. You then
use the <b>Reload Remote System Explorer</b> action, located on the
pop-up menu, to make the Remote System Explorer know about these
changes.&nbsp; You can also, of course, quit and restart the
workbench.&nbsp; See the related tasks for more information.</p>
changes. You can also, of course, quit and restart the
workbench. See the related tasks for more information.</p>
<p>Any resources received that are in a profile that you have already
active, such
as Team, will immediately be available and accessible to you. However,

8
rse/doc/org.eclipse.rse.doc.user/concepts/cuniversal.html
View file

@ -13,10 +13,10 @@
<a name="cuniversal"><!-- --></a>
<h1 class="topictitle1">Universal Systems</h1>
<div>
<p>At a minimum the Remote System Explorer provides access to&nbsp;
<p>At a minimum the Remote System Explorer provides access to
Linux,
UNIX, and Windows systems.&nbsp; These are called "universal" systems
since their file and command systems are quite similar.&nbsp; You can
UNIX, and Windows systems. These are called "universal" systems
since their file and command systems are quite similar. You can
export,
import, explore remote files, and run remote
commands on all of these system types.
@ -28,7 +28,7 @@ from one Linux host to another, or from one
file in your Linux host to another file in
the same host.</p>
<p>The Remote System Explorer can also provide access to other types of
systems if the support is installed in the workbench.&nbsp; Examples of
systems if the support is installed in the workbench. Examples of
such systems might be IBM iSeries or zSeries server systems.<br/>
</p>
<p>Expand the topics in the help contents or click the following links

2
rse/doc/org.eclipse.rse.doc.user/concepts/cuseractions.html
View file

@ -31,7 +31,7 @@ the command is run.</li>
for example,
whether to prompt first.</li>
<li>One or more file types that limit the action to specific types of
remote resources. For example, a command to start&nbsp; a program that
remote resources. For example, a command to start a program that
searches text files could be limited to just text files. The action is
only shown
for remote objects which is one of the specified types.</li>

8
rse/doc/org.eclipse.rse.doc.user/tasks/tteamsup.html
View file

@ -32,14 +32,14 @@ or not to activate these profiles in the Team view if you want to see the
profile's contents in the Remote System Explorer on your local workstation.</div>
<p>In a team programming environment, team members do work in their own workbench,
isolated from others. Eventually they will want to share their work with
their teammates.&nbsp; The Remote System Explorer allows them to share
their teammates. The Remote System Explorer allows them to share
their connections, filter pools, and filters. To share these resources:</p>
</div>
<ol>
<li class="skipspace">In the Remote System Explorer perspective, select the Team tab which by
default is located in the same pane as the Remote Systems view.&nbsp; This
will bring the Team view to the front of the Remote System Explorer.&nbsp;
You can also use the&nbsp;<img src="../images/gsarrow.gif" title="" alt="menu" style="width: 24px; height: 23px;"/>
default is located in the same pane as the Remote Systems view. This
will bring the Team view to the front of the Remote System Explorer.
You can also use the<img src="../images/gsarrow.gif" title="" alt="menu" style="width: 24px; height: 23px;"/>
button on the Remote Systems view and select the <span style="font-weight: bold;">Work
With Profiles</span> action.<span> </span></li>
<li class="skipspace"><span>Expand <b>RemoteSystemsConnections</b>. The profiles that you have defined, as well as the Team profile, are displayed. The Team profile is created by the Remote System Explorer to use for sharing connections, filter pools, and filters if you do not want to share them in a profile that you create and manage.</span></li>

4
rse/doc/org.eclipse.rse.doc.user/tasks/tteamsup1.html
View file

@ -27,9 +27,9 @@ view to work with or activate your non-active profiles.
<div class="p">
<ol>
<li>In the Remote Systems perspective, select the Team tab which by
default is located in the same pane as the Remote Systems view.&nbsp;
default is located in the same pane as the Remote Systems view.
This will bring the Team view to the front of the Remote System
Explorer.&nbsp; You can also use the&nbsp;
Explorer. You can also use the
<img src="../images/gsarrow.gif" title="" alt="menu" style="width: 24px; height: 23px;"/>
button on the Remote Systems view and select the <span style="font-weight: bold;">Work With Profiles</span>
action.<br/>

2
rse/examples/org.eclipse.rse.remotecdt/remotecdt.html
View file

@ -3,7 +3,7 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<meta name="copyright" content="Copyright (c) 2006 PalmSource, Inc. and others. This page is made available under license. For full details see the LEGAL notice in the documentation book that contains this page." >
<meta name="copyright" content="Copyright (c) 2006 PalmSource, Inc. and others. This page is made available under license. For full details see the LEGAL notice in the documentation book that contains this page." />
<link rel="stylesheet" type="text/css" href="../org.eclipse.rse.doc.user/book.css" />
<title>Launching Remote C/C++ Applications</title>
</head>

6
rse/tests/org.eclipse.rse.tests.framework/html/futures.html
View file

@ -3,10 +3,10 @@
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Artemis Test Framework</title>
<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"/>
<meta http-equiv="Content-Style-Type" content="text/css" />
<link rel="stylesheet" type="text/css" href="../book.css" />
</head>
<body>
<h2>Future Items</h2>

13
rse/tests/org.eclipse.rse.tests.framework/html/plugging.html
View file

@ -3,10 +3,10 @@
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Artemis Test Framework</title>
<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"/>
<meta http-equiv="Content-Style-Type" content="text/css" />
<link rel="stylesheet" type="text/css" href="../book.css" />
</head>
<body>
<h2>Plugging into the Test Suite View</h2>
@ -23,7 +23,6 @@
&lt;type ... /&gt;
&lt;/extension&gt;
</pre>
</p>
<h3>Defining A Test Suite</h3>
<p>An existing JUnit test suite can be registered as follows:</p>
<pre class="code">
@ -62,7 +61,7 @@
<code>junit.framework.TestCase</code>. This allows you to use the <code>remark(String)</code>
method in your testcases to cause a line to be printed in the results pane before the final status of
the tests. It's a reasonable replacement for <code>System.out.println()</code>
if you want to have extra stuff print for your tests.
if you want to have extra stuff print for your tests.</p>
<h3>How Your Test Is Run</h3>
<p>You test suite will run inside of a eclipse user job.
This means you don't have direct access to the UI thread or
@ -71,13 +70,13 @@
testing support will provide the ability for testing UI constructs from the test job.</p>
<h3>Configuration And Prerequisites</h3>
<p>The Test Suite View is contributed by the plugin
<code>org.eclipse.rse.tests.framework</code>.
<code>org.eclipse.rse.tests.framework</code>.</p>
<p>Your test suites need only require those plugins that you directly
reference -- which would be at least the <code>org.junit</code> plugin. If
you implement TestSuiteProvider or use any of the utility classes for annotating
the result log you must also require <code>org.eclipse.rse.tests.framework</code>.</p>
<p>The plugin <code>org.eclipse.rse.tests.framework</code> does not
depend on anything other than <code>org.junit</code> and
<code>org.eclipse.*</code> plugins.
<code>org.eclipse.*</code> plugins.</p>
</body>
</html>

2
rse/tests/org.eclipse.rse.tests.framework/html/purpose.html
View file

@ -1 +1 @@
<?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>
<?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>

2
rse/tests/org.eclipse.rse.tests.framework/html/view.html
View file

@ -1 +1 @@
<?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" xml:lang="en" lang="en"> <head> <title>Artemis 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>Using The Test Suite View</h2> <p><img src="SampleWindow.jpg" alt="Sample Test Suite View"/></p> <p>The <strong>Test Suite View</strong> shows the registered test suites in the workbench. The view allows them to be sorted by clicking on the column headings, run individually, run in batches, run in the background or in the UI thread. You can reset the tests and re-run them. This is useful when debugging the function driven by a test, when debugging the test itself, or when testing varitions between intial and subsequent runs. You can also see the test results of any test suite that has been run.</p> <p>To open the Test Suite View use the Window -> Show View -> Other... menu item and select the Test Suites View from the Testing category. <h3>Columns</h3> <p>The <strong>Graphic</strong> column shows the status of the test. It show a question mark if the test has not been run or has been reset, a red X if the test suite has a test case that has failed or produced an exception, and a green check if the test has run to completion. In keeping with the philosophy of JUnit it is updated as the test suite is run so you know immediately if there are any failures.</p> <p>The <strong>Test Suite</strong> columns show the name of the test suite.</p> <p>The <strong>Summary</strong> column is blank if the test has not yet been run. It shows the number of test cases run, the number failed, and the number of unexpected errors. It is updated as the test suite is run.</p> <p>The <strong>Time Run</strong> column is blank if the test has not yet been run. It shows the time the test suite began running, not the time it finished.</p> <h3>Actions</h3> <p>You bring up a context menu containing the test suite actions by selecting a test suite (or several) and right-clicking. The actions may be grayed out if they are not available for that particular selection of tests. You select tests by clicking on them. You can add test suites to (and remove test suites from) the selection by using control-click. You can select a range of tests by using shift-click.</p> <dl> <dt>Select All</dt> <dd>The "Select All" action selects all the test suites in the view. It is available no matter how many test suites are currently selected.</dd> <dt>Run</dt> <dd>This action will run the selected test suites, in the order in which they are presented in the list. The suites are run in an eclipse "job" that can be relegated to the background. The Test Suite View is busy while the tests are being run. This action is available if there is at least one test suite selected.</dd> <dt>Reset</dt> <dd>The "Reset" action will erase the results of the selected test suites and show them as "not yet run". It is available if there is at least one test suite selected.</dd> </dl> <h3>The Results Pane</h3> <img src="ResultsPane.jpg" alt="Results Pane"/> <p>The <strong>Results Pane</strong> shows the results of a test suite that has been run. Each test case in the suite has an entry that shows its success or failure with any remarks generated by a testcase during its run. If the test case fails, the entry shows the reason for the failure along with the stack trace for the exception. The results pane may be copied so you can place it in a defect or an e-mail.</p> <p>You can move the divider between the Test Suite Pane and the Results Pane up and down as necessary. </body> </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" xml:lang="en" lang="en"> <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>Using The Test Suite View</h2> <p><img src="SampleWindow.jpg" alt="Sample Test Suite View" /></p> <p>The <strong>Test Suite View</strong> shows the registered test suites in the workbench. The view allows them to be sorted by clicking on the column headings, run individually, run in batches, run in the background or in the UI thread. You can reset the tests and re-run them. This is useful when debugging the function driven by a test, when debugging the test itself, or when testing varitions between intial and subsequent runs. You can also see the test results of any test suite that has been run.</p> <p>To open the Test Suite View use the Window -> Show View -> Other... menu item and select the Test Suites View from the Testing category.</p> <h3>Columns</h3> <p>The <strong>Graphic</strong> column shows the status of the test. It show a question mark if the test has not been run or has been reset, a red X if the test suite has a test case that has failed or produced an exception, and a green check if the test has run to completion. In keeping with the philosophy of JUnit it is updated as the test suite is run so you know immediately if there are any failures.</p> <p>The <strong>Test Suite</strong> columns show the name of the test suite.</p> <p>The <strong>Summary</strong> column is blank if the test has not yet been run. It shows the number of test cases run, the number failed, and the number of unexpected errors. It is updated as the test suite is run.</p> <p>The <strong>Time Run</strong> column is blank if the test has not yet been run. It shows the time the test suite began running, not the time it finished.</p> <h3>Actions</h3> <p>You bring up a context menu containing the test suite actions by selecting a test suite (or several) and right-clicking. The actions may be grayed out if they are not available for that particular selection of tests. You select tests by clicking on them. You can add test suites to (and remove test suites from) the selection by using control-click. You can select a range of tests by using shift-click.</p> <dl> <dt>Select All</dt> <dd>The "Select All" action selects all the test suites in the view. It is available no matter how many test suites are currently selected.</dd> <dt>Run</dt> <dd>This action will run the selected test suites, in the order in which they are presented in the list. The suites are run in an eclipse "job" that can be relegated to the background. The Test Suite View is busy while the tests are being run. This action is available if there is at least one test suite selected.</dd> <dt>Reset</dt> <dd>The "Reset" action will erase the results of the selected test suites and show them as "not yet run". It is available if there is at least one test suite selected.</dd> </dl> <h3>The Results Pane</h3> <img src="ResultsPane.jpg" alt="Results Pane" /> <p>The <strong>Results Pane</strong> shows the results of a test suite that has been run. Each test case in the suite has an entry that shows its success or failure with any remarks generated by a testcase during its run. If the test case fails, the entry shows the reason for the failure along with the stack trace for the exception. The results pane may be copied so you can place it in a defect or an e-mail.</p> <p>You can move the divider between the Test Suite Pane and the Results Pane up and down as necessary.</p> </body> </html>