Test Definition Editor

Courses in c#, ruby, shell scripting, Software testing courses and more See a video tour Thwameva technologies offers a state of the art advanced training using multimedia video mentoring , practical oriented training and experts as mentors(*). Thwameva offers software testing courses, courses in WET, ruby, C#, shell scripting and more... The unique combination of video mentoring by experts and mentor assisted training programs are applicable only for software training courses in Thwameva's Bangalore office. Thwameva technologies is the primary sponsor for the WET project

Home Download Docs Support Project

User guide

WET provides a robust technique of organizing tests by means of a test definition file. You then use WetRunner to run your test. The test definition started off in our shop floor as a quick and dirty way of organizing a single testing. Over time, it is inching towards becoming one of the most powerful features of WET. Using Test Definitions, you can define a WET test to look similar to a manual test.

In this document we will see first about what a test defintion is all about and finally see how to use the test definition editor UI to create and edit test definitions.

Organization of a test:

A WET test is typically a compound folder. That is, the 'test' is actually a folder in your file system which has, a minimum of one file - the test definition file. The test definition file is a configuration file that has to be named as test.defs. This configuration file lets you set the paths to all other entities (like scripts, results, etc.), thereby allowing your test to be scattered at various places. However as a good practice, always organize your tests in a more orderly fashion. A suggested test folder structure could be :

<wet_tests>/$test_name--|

|- test.defs

|-scripts-|

|- $trans1.wet

|- $trans2.wet

|- ....

|- $transn.wet

|-results |

|- (test will

| create results)

|- data |

|- data.xls

Where $test_name is the actual name of your current test.

Note : The above folder structure is a suggestion for just one single test definition. The document, Wet for Web testing, describes the folder structure for the entire wet suite.

Test Definition File Properties

A test definition file is nothing but a property file which defines the various artifacts of the test. Each property item of the test definition is a name-value pair definition. While the name is a string literal, the value can either be a String literal or a ruby script which is evaluated at run time.

A test definition has the following categories.

Common These are properties that are common to the test as a whole

Preconditions To simulate a manual test, WET allows you to define one or more preconditions

Transactions A WET test can have one or more transactions.

Teardowns As in a real test, after completing the test it is required to restore the system to its previous state Teardowns are used to accomplish this

Common properties

These are the common properties which are applicable to the test as a whole

1) repository.path - Full path to the object repository file that your test will be using. This property is required when you use the xml based object repository for your tests.

2) results.path – The path to which the test results file will be saved after the test run

3) testdata.path - Full path to the testdata file to be used by the test. The datatable can be in any one of the following formats:

1. Excel sheet

2. XML Sheet

3. CSV

For a detailed description about datatables and how to use them, see the wiki page at http://wiki.openqa.org/display/WET/Data+driven+tests

4) obj.timeout  -  The amount of time in seconds that WET should wait when trying to find objects at run time. WET keeps retrying for this amount of time when it needs to find an object.

5) testdata.iterations - Whether the transactions are to be run for one single iteration or for all the rows of the datatable. If the value is set to *, then the test is executed for all the rows of the datatable. Otherwise, the test is executed only for those rows that the tester explicitly specifies in his scripts.

6) script.path – The script to be run, when this test is invoked as a library test. Starting from version 1.0, this parameter does not have too much of significance. In the previous versions, if a test definition were to be called as a library test, then the ruby file pointed by script.path was the script that was run invariably. However, starting off from WET 1.0, this has changed – WET 1.0 has a parameter called transaction_to_use which allows any test definition to be used as a parameter. Whenever a test definition is used as a library test, then the following logic is applied:

1. See if transaction_to_use is defined for the precondition or teardown. If yes, then use the ruby script pointed by the transaction_to_use parameter

2. If the parameter is not defined, then revert to the old method – use the ruby file pointed to by the script.path parameter.

Preconditions

A WET script can have zero or more preconditions. A Precondition is nothing but another WET script (a complex folder with a test definition file. For each precondition, the following parameters will be defined

1) name – A name given to identify this precondition

2) path – The path to the folder which has the test definition for this precondition.

3) transaction_to_use – Which transaction of the precondition's testdefintion should be used ?

4) param1 to paramN – Parameters to be passed to this precondition. While calling a precondition from a test definition, the precondition may be expecting parameters.

Transaction specific properties

You can have any number of transactions in your test. Each transaction defines the following parameters:

1) name – A name given to identify this transaction

2) path – The path to the WET script (not a folder – the actual script) which defines the actions and checks results for this transaction.

3) param1 to paramN – Parameters to be passed to this transaction.

Teardowns

A WET script can have zero or more teardowns. A Teardown is nothing but another WET script (a complex folder with a test definition file). For each teardown, the following parameters will be defined

1) name – A name given to identify this teardown

2) path – The path to the folder which has the test definition for this teardown.

3) transaction_to_use – Which transaction of the teardown's testdefinition should be used ?

4) param1 to paramN – Parameters to be passed to this teardown. While calling a teardown from a test definition, the teardown may be expecting parameters.

Test definition template

The following is the template for a test definition:

###########################################################

#Note : For all Common objects, the prop value

#can either be a string or a command to evaluate

#eg.

#eval /results2/

# or

#eval Mon Jun 18 02:17:05 India Standard Time 2007/results/

#NOTE : IF THE eval STRING HAS AN ERROR, THIS

#IS NOT HANDLED - EXECUTION HALTS WITH AN ERROR!!!

###########################################################

[Common]

##Name of the script

name=My test name

### The path to use for your object repository.

#repository.path = <your repository path>

### The path where the test results will be stored.

results.path = ./results/

### The path where the test data for this test is

### to be loaded from

#testdata.path = ./data/data.xls

#Should the script be run for each iteration?

#default = no. values can be 1 or * - to indicate

#one iteration or all iterations.

#testdata.iterations = 1

### Library path (not in use currently)

lib.path=

### Time in seconds, for which WET should wait before

### declaring that an object cannot be found

obj.timeout=10

## In case the test doesn't have transactions but only

## Has one single script to run, that will be defined here.

script.path = ../scripts/test.qws

###########################################################

[Precondition1]

name = P1

path = eval /lib/do_init

transaction_to_use = Login

param1 = pre_param1

param2 = pre_param2

[Precondition2]

name = P2

path = eval /lib/do_init

transaction_to_use = Go_Inbox

param1 = pre_param1

param2 = pre_param2

[PreconditionN]

name = Pn

path = eval /lib/do_init

transaction_to_use = Some_trans

param1 = pre_param1

param2 = pre_param2

##########################################################

### Details about the first transaction

[Transaction1]

name = T1

path = ../scripts/test.qws

#Add any number of parameters that you want to here:

param1 = FirstParameter

param2 = SecondParameter

### Details about other transactions, if any

### A test should have a minimum of one transaction.

###########################################################

[Teardown1]

name = Td1

path = eval /lib/do_clean

transaction_to_use = Logout

param1 = td_param1

param2 = td_param2

[TeardownN]

name = Tdn

path = eval /lib/do_clean

transaction_to_use = Some_trans

param1 = td_param1
param2 = td_param2

Using test definition parameters that are to be evaluated at run time.

The values of various parameters in the test definition file are usually literal values. However there are many a time when you want these values to be evaluated at run time. For example, you may want to save the test execution result for each test run to a directory dependant on the time of execution. WET has a way that allows you to specify that the value is to be evaluated at run time rather than to use a hardcoded string literal. The value to be evaluated at run time will be a ruby command. The syntax to do this is to

1. Start the value with the 'eval' keyword

2. enclose the ruby command to be evaluated inside a block

3. If the above 2 are followed, then you may combine an evaluable value with a string literal in any fashion that you need.

Examples of how to use evaluated test definitions:

results.path = eval Mon Jun 18 02:17:05 India Standard Time 2007/results/

results.path = eval /wet_tests/Execution_Mon Jun 18 02:17:05 India Standard Time 2007/results/

Test Definition UI

The test definition editor application is used to create test definition files that can be used in WET automation. The test definition Editor in version 1.0 does not try to do anything smart. (in the previous version, the test definition editor was trying to interact with other entities like the transaction scripts, object depot etc., and at times this interaction was confusing) It acts as a (almost) dumb editor. For example, when you set the object depot file or transaction path using the test definition editor, then it does not try to check if the file exists or not and in case the file doesn't exist, it doesn't try to create one for you. Instead, it simply creates a test definition used to play back the automation. The test definition editor also has an abilities to execute tests from the UI itself. The result of test execution is then shown in a different web browser.

Illustration 1: Test definition editor upon startup

Creating new test definitions and opening existing test definitions

The file menu, as in most windows applications, has options to allow creation of new test definitions, save test definitions and open previously saved test definitions.

Editing test definitions

Using the test definition editor, almost all the parameters of a test definition can be edited. While the parameter values can be edited using the panel provided in the UI, the edit menu is used to add or delete new preconditions, teardowns and transactions.

Name : The name of the test definition is nothing but the name of the topmost node of the treeview. You can edit the name of the test defnition by editing the tree node's name.

Other Common parameters: All the other common parameters of the test definition can be edited by changing the appropriate parameter on the right hand panel. The labels of the various fields on the right handside are quite intutive w.r.t the the test definition parameter that they actually represent. For example, the 'description' field is used to change the Common header's description, results path is used to change the common header's 'results.path' and so on.

Adding preconditions : If you want to add preconditions, then use the Edit -> Preconditions -> Add new menu to add preconditions.

Editing preconditions : To edit the name of the precondition, simply select the precondition and edit the treenode's name. To edit the various parameters of the precondition, select the precondition and change the appropriate value on the right hand panel. Just as in the main test definition, the fields on the right hand side are very obvious about what parameter they are actually setting. However there are a few points that need to be noted here:

Path

The precondition path can be either set by choosing a file in the file system or by directly setting the value. The latter is useful either because you want to simply create the test definition for the precondition later on or because you dont want to use absolute paths.

To set the value to an existing file in the file system, simply say choose in the drop-down box right next to the path. Then a open file dialog shows up from which you can select the test definition file that becomes the precondition path.

To set the value to a string literal, use the set option in the drop-down box next to the path. A small dialog shows up in which you can set the value of the path. You may either provide a string literal as the path value or an 'evaluable' path.

Transaction to use

The transaction which is to be used as the precondition can be selected from the transaction to use drop-down box. This drop-down is automatically populated to the correct values depending on the Path parameter.

Parameters

The parameters to be passed to the parameters can be set using the datagrid at the bottom of the right hand side panel.

Deleting preconditions : If you want to delete a precondition, then use the Edit -> Preconditions -> Delete menu to delete preconditions.

Adding, editing and deleting transactions : Working with transactions is exactly similar to the way that you worked with preconditions. The only notable difference between the two is that whenever you choose or set a path in the script path, then the actual script is displayed on the right hand side read-only panel.

Adding, editing and deleting teardowns : Working with teardowns is exactly similar to the way that you work with preconditions – both of them are library tests anyway.

Executing tests

The Tools -> Execute menu has an option to execute test cases directly. You must have saved the test definition before attempting to execute the test definition. When you use this option, the test definition is executed and the results are generated. As soon as the test is completed, a detailed status about the status is displayed

Summary

Test definitions in WET are a slick way of organizing test suites to follow the same pattern as manual test cases. The test definition is a configuration file which describes all the details about the test. Test definitions can be created and edited using the Test Definition Editor which is a windows application.