From 026349d6990d6ac1038eb434bf7dfd317ef9a828 Mon Sep 17 00:00:00 2001 From: David Dykstal Date: Thu, 22 Feb 2007 21:15:24 +0000 Subject: [PATCH] [174770][doc] removing  , adding missing closing tags, fixing nesting and ids. --- .../org.eclipse.dstore.doc.isv/guide/Artifacts.html | 2 +- .../guide/Communications.html | 3 +-- .../guide/DataElements.html | 6 +++--- .../guide/plugin/subsystem.html | 8 ++++---- .../org.eclipse.rse.doc.user/concepts/cbegin.html | 4 +--- .../org.eclipse.rse.doc.user/concepts/cfilters.html | 4 ++-- .../org.eclipse.rse.doc.user/concepts/cprofile.html | 2 +- .../concepts/cremcompile.html | 6 +++--- .../org.eclipse.rse.doc.user/concepts/cteam.html | 6 +++--- .../concepts/cuniversal.html | 8 ++++---- .../concepts/cuseractions.html | 2 +- .../org.eclipse.rse.doc.user/tasks/tteamsup.html | 8 ++++---- .../org.eclipse.rse.doc.user/tasks/tteamsup1.html | 4 ++-- .../org.eclipse.rse.remotecdt/remotecdt.html | 2 +- .../html/futures.html | 6 +++--- .../html/plugging.html | 13 ++++++------- .../html/purpose.html | 2 +- .../org.eclipse.rse.tests.framework/html/view.html | 2 +- 18 files changed, 42 insertions(+), 46 deletions(-) diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/Artifacts.html b/rse/doc/org.eclipse.dstore.doc.isv/guide/Artifacts.html index 3b35774b087..a45c4741edb 100755 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/Artifacts.html +++ b/rse/doc/org.eclipse.dstore.doc.isv/guide/Artifacts.html @@ -17,7 +17,7 @@
  • DataElement
  • Miner
    • -

    All the classes and interfaces mentioned here are defined in the org.eclipse.dstore.core plugin. +

    All the classes and interfaces mentioned here are defined in the org.eclipse.dstore.core plugin.

    Client Connection

    diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/Communications.html b/rse/doc/org.eclipse.dstore.doc.isv/guide/Communications.html index 3cad8e80440..3446f6fd8ec 100755 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/Communications.html +++ b/rse/doc/org.eclipse.dstore.doc.isv/guide/Communications.html @@ -78,6 +78,7 @@ over the network. For its handlers, the local DataStore uses a Client Update

    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. +

    1. @@ -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.
    -

    Client/Server DataStore

    @@ -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. -

    \ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/DataElements.html b/rse/doc/org.eclipse.dstore.doc.isv/guide/DataElements.html index 50eb1468e37..59745c901e5 100755 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/DataElements.html +++ b/rse/doc/org.eclipse.dstore.doc.isv/guide/DataElements.html @@ -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 getAttribute(attribute index). A particular attribute is set by calling setAttribute(attribute index, attribute value). The attribute indices that can be used are as follows: +

    @@ -23,9 +24,8 @@ The attribute indices that can be used are as follows: -. +
    AttributeDescription
    A_TYPEAttribute 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.
    A_VALUEAttribute indicating the more information about that object
    A_SOURCEAttribute indicating source information about an object, if applicable
    A_REF_TYPEAttribute 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 Memory Management in DataStore
    A_IDThe unique ID of a DataElement.
    A_IDThe unique ID of a DataElement.
    -

    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, descriptors, 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 A_SOURCE attribute indicates to the DataStore that an instance of that command should be routed to that miner when it's issued. -

    +

    See the section, Miners to find out how miners contribute schemas diff --git a/rse/doc/org.eclipse.rse.doc.isv/guide/plugin/subsystem.html b/rse/doc/org.eclipse.rse.doc.isv/guide/plugin/subsystem.html index 10b21ae6037..7ed28413a59 100755 --- a/rse/doc/org.eclipse.rse.doc.isv/guide/plugin/subsystem.html +++ b/rse/doc/org.eclipse.rse.doc.isv/guide/plugin/subsystem.html @@ -197,10 +197,10 @@ following summarizes the minimum set of classes you will be creating in order to in the startup() 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:
    -   MyAdapterFactory factory = new MyAdapterFactory(); // extends AbstractSystemRemoteAdapterFactory
    -   IAdapterManager manager = Platform.getAdapterManager();
    -   manager.registerAdapters(factory, MyModelObject1.class);
    -   manager.registerAdapters(factory, MyModelObject2.class);
    + MyAdapterFactory factory = new MyAdapterFactory(); // extends AbstractSystemRemoteAdapterFactory
    + IAdapterManager manager = Platform.getAdapterManager();
    + manager.registerAdapters(factory, MyModelObject1.class);
    + manager.registerAdapters(factory, MyModelObject2.class);

  • If your filter string from step 5 is complicated enough, you will probably find the diff --git a/rse/doc/org.eclipse.rse.doc.user/concepts/cbegin.html b/rse/doc/org.eclipse.rse.doc.user/concepts/cbegin.html index 22d12e63f18..039c6f323a2 100755 --- a/rse/doc/org.eclipse.rse.doc.user/concepts/cbegin.html +++ b/rse/doc/org.eclipse.rse.doc.user/concepts/cbegin.html @@ -42,9 +42,7 @@ filter pools, and filter pool references, which list a set of folders and files from your server in the Remote Systems view.

    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.  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.

    diff --git a/rse/doc/org.eclipse.rse.doc.user/concepts/cfilters.html b/rse/doc/org.eclipse.rse.doc.user/concepts/cfilters.html index 939d2246675..dd2c8ab5ea3 100755 --- a/rse/doc/org.eclipse.rse.doc.user/concepts/cfilters.html +++ b/rse/doc/org.eclipse.rse.doc.user/concepts/cfilters.html @@ -29,9 +29,9 @@ these tasks on these remote resources by using filters that show these resources at your workstation.

    The Remote System Explorer perspective is designed to allow you to -manipulate the resources directly on the remote system.  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.  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.

    diff --git a/rse/doc/org.eclipse.rse.doc.user/concepts/cprofile.html b/rse/doc/org.eclipse.rse.doc.user/concepts/cprofile.html index e9a8d5dc87d..0f204179c75 100755 --- a/rse/doc/org.eclipse.rse.doc.user/concepts/cprofile.html +++ b/rse/doc/org.eclipse.rse.doc.user/concepts/cprofile.html @@ -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.  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. diff --git a/rse/doc/org.eclipse.rse.doc.user/concepts/cremcompile.html b/rse/doc/org.eclipse.rse.doc.user/concepts/cremcompile.html index f27a7a409d7..69e03fed50d 100755 --- a/rse/doc/org.eclipse.rse.doc.user/concepts/cremcompile.html +++ b/rse/doc/org.eclipse.rse.doc.user/concepts/cremcompile.html @@ -14,7 +14,7 @@

    Compiling Programs

    You can run a compile command on a server from the Remote System -Explorer perspective.  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.

    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.  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.

    IBM supplies a number of default compile commands for common file types and you can also add -your own.  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.

    See the related topics below for more information.

    diff --git a/rse/doc/org.eclipse.rse.doc.user/concepts/cteam.html b/rse/doc/org.eclipse.rse.doc.user/concepts/cteam.html index cc211fbc02f..d4640ac3930 100755 --- a/rse/doc/org.eclipse.rse.doc.user/concepts/cteam.html +++ b/rse/doc/org.eclipse.rse.doc.user/concepts/cteam.html @@ -13,7 +13,7 @@

    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.  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 Reload Remote System Explorer action, located on the pop-up menu, to make the Remote System Explorer know about these -changes.  You can also, of course, quit and restart the -workbench.  See the related tasks for more information.

    +changes. You can also, of course, quit and restart the +workbench. See the related tasks for more information.

    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, diff --git a/rse/doc/org.eclipse.rse.doc.user/concepts/cuniversal.html b/rse/doc/org.eclipse.rse.doc.user/concepts/cuniversal.html index 6424fcba0eb..c311ad2b0bd 100755 --- a/rse/doc/org.eclipse.rse.doc.user/concepts/cuniversal.html +++ b/rse/doc/org.eclipse.rse.doc.user/concepts/cuniversal.html @@ -13,10 +13,10 @@

    Universal Systems

    -

    At a minimum the Remote System Explorer provides access to  +

    At a minimum the Remote System Explorer provides access to Linux, -UNIX, and Windows systems.  These are called "universal" systems -since their file and command systems are quite similar.  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.

    The Remote System Explorer can also provide access to other types of -systems if the support is installed in the workbench.  Examples of +systems if the support is installed in the workbench. Examples of such systems might be IBM iSeries or zSeries server systems.

    Expand the topics in the help contents or click the following links diff --git a/rse/doc/org.eclipse.rse.doc.user/concepts/cuseractions.html b/rse/doc/org.eclipse.rse.doc.user/concepts/cuseractions.html index 888840e30c6..ced73ab69f2 100755 --- a/rse/doc/org.eclipse.rse.doc.user/concepts/cuseractions.html +++ b/rse/doc/org.eclipse.rse.doc.user/concepts/cuseractions.html @@ -31,7 +31,7 @@ the command is run.

    • for example, whether to prompt first.
  • One or more file types that limit the action to specific types of -remote resources. For example, a command to start  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.
    • diff --git a/rse/doc/org.eclipse.rse.doc.user/tasks/tteamsup.html b/rse/doc/org.eclipse.rse.doc.user/tasks/tteamsup.html index b2de2f55420..88fb6da8b80 100755 --- a/rse/doc/org.eclipse.rse.doc.user/tasks/tteamsup.html +++ b/rse/doc/org.eclipse.rse.doc.user/tasks/tteamsup.html @@ -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.

    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.  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:

    1. In the Remote System Explorer perspective, select the Team tab which by - 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 menu + 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 themenu button on the Remote Systems view and select the Work With Profiles action.
    2. Expand RemoteSystemsConnections. 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.
      3. diff --git a/rse/doc/org.eclipse.rse.doc.user/tasks/tteamsup1.html b/rse/doc/org.eclipse.rse.doc.user/tasks/tteamsup1.html index a2944670fea..56056f2950f 100755 --- a/rse/doc/org.eclipse.rse.doc.user/tasks/tteamsup1.html +++ b/rse/doc/org.eclipse.rse.doc.user/tasks/tteamsup1.html @@ -27,9 +27,9 @@ view to work with or activate your non-active profiles.
      1. In the Remote Systems perspective, select the Team tab which by -default is located in the same pane as the Remote Systems view.  +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  +Explorer. You can also use the menu button on the Remote Systems view and select the Work With Profiles action.
        diff --git a/rse/examples/org.eclipse.rse.remotecdt/remotecdt.html b/rse/examples/org.eclipse.rse.remotecdt/remotecdt.html index 04dc3a22e8e..37ecd4fbb53 100644 --- a/rse/examples/org.eclipse.rse.remotecdt/remotecdt.html +++ b/rse/examples/org.eclipse.rse.remotecdt/remotecdt.html @@ -3,7 +3,7 @@ - + Launching Remote C/C++ Applications diff --git a/rse/tests/org.eclipse.rse.tests.framework/html/futures.html b/rse/tests/org.eclipse.rse.tests.framework/html/futures.html index 1a9d329543c..070be70b2a7 100644 --- a/rse/tests/org.eclipse.rse.tests.framework/html/futures.html +++ b/rse/tests/org.eclipse.rse.tests.framework/html/futures.html @@ -3,10 +3,10 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> - Artemis Test Framework + RSE Test Framework - - + +

        Future Items

        diff --git a/rse/tests/org.eclipse.rse.tests.framework/html/plugging.html b/rse/tests/org.eclipse.rse.tests.framework/html/plugging.html index 1f3fdb90578..2115f258459 100644 --- a/rse/tests/org.eclipse.rse.tests.framework/html/plugging.html +++ b/rse/tests/org.eclipse.rse.tests.framework/html/plugging.html @@ -3,10 +3,10 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> - Artemis Test Framework + RSE Test Framework - - + +

        Plugging into the Test Suite View

        @@ -23,7 +23,6 @@ <type ... /> </extension> -

        Defining A Test Suite

        An existing JUnit test suite can be registered as follows:

        @@ -62,7 +61,7 @@
     junit.framework.TestCase.  This allows you to use the remark(String)
      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 System.out.println()
-     if you want to have extra stuff print for your tests.
+     if you want to have extra stuff print for your tests.
        
     
        How Your Test Is Run
        
     
        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.
        
     
        Configuration And Prerequisites
        
     
        The Test Suite View is contributed by the plugin 
-    org.eclipse.rse.tests.framework.
+    org.eclipse.rse.tests.framework.
        
     
        Your test suites need only require those plugins that you directly 
     reference -- which would be at least the org.junit plugin. If 
     you implement TestSuiteProvider or use any of the utility classes for annotating 
     the result log you must also require org.eclipse.rse.tests.framework.
        
     
        The plugin org.eclipse.rse.tests.framework does not 
     depend on anything other than org.junit and 
-    org.eclipse.* plugins.
+    org.eclipse.* plugins.
        
 
 
diff --git a/rse/tests/org.eclipse.rse.tests.framework/html/purpose.html b/rse/tests/org.eclipse.rse.tests.framework/html/purpose.html
index 1270e2eaaf2..6d286d6b0ec 100644
--- a/rse/tests/org.eclipse.rse.tests.framework/html/purpose.html
+++ b/rse/tests/org.eclipse.rse.tests.framework/html/purpose.html
@@ -1 +1 @@
-



    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 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 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.
        


\ No newline at end of file
+



    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.
        


\ No newline at end of file
diff --git a/rse/tests/org.eclipse.rse.tests.framework/html/view.html b/rse/tests/org.eclipse.rse.tests.framework/html/view.html
index 36bc5b01d2a..ac7fa3fd51d 100644
--- a/rse/tests/org.eclipse.rse.tests.framework/html/view.html
+++ b/rse/tests/org.eclipse.rse.tests.framework/html/view.html
@@ -1 +1 @@
-



    Artemis Test Framework
    
    
    


    
        Using The Test Suite View
        
    
        Sample Test Suite View
        
    
        The Test Suite View 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.
        
    
        To open the Test Suite View use the Window -> Show View -> Other... menu 
    item and select the Test Suites View from the Testing category.
    
        Columns
        
    
        The Graphic 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.
        
    
        The Test Suite columns show the name of the test suite.
        
    
        The Summary 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.
        
    
        The Time Run 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.
        
    
        Actions
        
    
        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.
        
    
        
        
        Select All
        
        
        The "Select All" action selects all the test suites in the view. 
        It is available no matter how many test suites are currently selected.
        
        
        Run
        
        
        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.
        
        
        Reset
        
        
        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.
        
    
        
    
        The Results Pane
        
    Results Pane
    
        The Results Pane 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.
        
    
        You can move the divider between the Test Suite Pane and the Results Pane up and 
    down as necessary.


\ No newline at end of file
+



    RSE Test Framework
    
    
    


    
        Using The Test Suite View
        
    
        Sample Test Suite View
        
    
        The Test Suite View 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.
        
    
        To open the Test Suite View use the Window -> Show View -> Other... menu 
    item and select the Test Suites View from the Testing category.
        
    
        Columns
        
    
        The Graphic 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.
        
    
        The Test Suite columns show the name of the test suite.
        
    
        The Summary 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.
        
    
        The Time Run 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.
        
    
        Actions
        
    
        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.
        
    
        
        
        Select All
        
        
        The "Select All" action selects all the test suites in the view. 
        It is available no matter how many test suites are currently selected.
        
        
        Run
        
        
        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.
        
        
        Reset
        
        
        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.
        
    
        
    
        The Results Pane
        
    Results Pane
    
        The Results Pane 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.
        
    
        You can move the divider between the Test Suite Pane and the Results Pane up and 
    down as necessary.
        


\ No newline at end of file