3.12.3. Creating tests from the library of pre-defined Test Cases
Prev | 3.12. Working with Test Cases | Next

### 3.12.3. Creating tests from the library of pre-defined Test Cases

Everything you need to create tests is already available for you in each Project. The library of Test Cases which appears automatically in each new Project contains all the actions supported for testing as well as some examples of more complex keywords. For general information about the library, read the section later on (Section 3.12.3.2, “Information about the library”). To learn how to use the library to create tests, read the next Section 3.12.3.1, “Using the library to create tests”.

#### 3.12.3.1. Using the library to create tests

Creating tests with the ITE is really just a matter of:

- Deciding how to structure your tests (i.e. what keywords to create and how to combine them).

- Choosing the Test Cases from the library (or from your own set of Test Cases) that you need to create these keywords.

To use the Test Cases from the library, you will first need to create a Test Case of your own (Section 3.12.2, “Creating Test Cases”).

1. Open the Test Case Editor by double-clicking on the Test Case you want to edit in the Test Case Browser.

2. In the Test Case Browser, browse to a Test Case that you want to add. For help on finding your way around the library, see the later Section 3.12.3.3, “Tips and tricks for using the Test Case library”.

3. You can add the Test Case by dragging and dropping from the Test Case Browser to the Test Case Editor or you can right click on the Test Case in the Test Case Editor and select:

   Reference Existing Test Case

   to see a list of all Test Cases that you can add to this Test Case.

   | You can filter in this dialog using the field at the top. Use star * as a wild card.

   | You can open the dialog to reference an existing Test Case by pressing »ENTER« on a Test Case in the Test Case Editor.

4. Once you have added the Test Case, you will need to enter a component name in the Component Names View (Section 3.15.3, “Entering and reassigning component names in the Component Names View”) and you will need to enter data for the Test Case in the Properties View (Section 3.14, “Working with test data”).

#### 3.12.3.2. Information about the library

1. You can use a highly reusable library of Test Cases to specify tests.

2. The Projects containing the Test Case libraries are located under:

   examples/testcaseLibrary.

3. The Projects available are:

   - unbound_modules_concrete

   - unbound_modules_web

   - unbound_modules_swt

   - unbound_modules_rcp

4. These Projects contain reusable Test Cases which have been created in advance so you do not have to specify them yourself.

   | Refer to the chapter on Components, Actions, and Parameters for information on components, the actions they support, and their parameters.

5. The library is split into categories of actions on components. To select something in your AUT, open the select category and then open the category for the type of component you want to select something from.

   | The names for these Test Cases all begin with ”ub”. This means that they are unbound -- they are not in any way dependent on an AUT.

6. Each Test Case in the library contains one Test Step which corresponds to the action in the Test Case name. The component name is a placeholder, and the parameters have been referenced so that you can enter your own data.

   | The unbound modules Projects which correspond to your chosen Project toolkit are automatically imported into the database and reused in your Project.

   | We do not recommend making changes to the installed unbound module Projects, for compatibility reasons. If you have Test Cases you want to reuse in other Projects, we advise creating your own library Project.

#### 3.12.3.3. Tips and tricks for using the Test Case library

The Test Cases in the library are organised into actions. In the basic category, you will find the various actions offered for testing. The complex category contains some example keywords which are built up of more than one Test Case.

When specifying your tests, you need to find and choose which actions you will need. This takes some practice, but there are some hints which can help you:

High-Level Actions
During a test, high-level actions are executed. This means that if you want to select something from a menu using the menupath, for example, you need to look in the category:

Actions (basic)/Select/Menu Bar

and select the Test Case:

ub_mbr_selectEntry_byTextpath

The Test Case finds the menu, opens it, and clicks the item you specify.

Abstract components
There are some actions which are executable on many different components. Clicks, for example can be executed on pratically all components in the interface. You can also check text on labels, combo boxes and text fields. Obviously, it makes sense to specify your Test Cases as abstractly as possible so that they can be reused in more places. This helps keep the maintenance low later.

You will notice in the library that there is no Button category under the Click category. Instead, you will find various click actions specified for Graphics Component (grc). This is because all components which support clicks belong to the Graphics Component group.

In the same way, you will find the category Check/Component with Text. You can use the check actions from this category to check text on any component with text – buttons, text fields, combo boxes, labels.

Parameters
Different actions require different data. Some Test Cases in the library have been pre-configured with data to make test specification easier (look in the category Input via Keyboard/Application/Key Combination for a long list).

Some actions let you choose whether you want to enter data using an indexpath or a textpath. We recommend using the textpath so that you are not dependent on the order of e.g. menu entries or tabbed panes.

To make text-based parameters more robust, you can often choose an operator. You can choose between equals, matches, simple match, not equals. Using matches lets you use regular expressions so that you don’t have to hard-code the whole text parameter.