Open source web testing tool
The future of automated web testing is open source

API Guide - WET Test Case

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
Main       Web Objects       Win Objects       Test Mgmt       Others      

Singleton class that helps to define what a test looks like. The lone instance of this class loads script properties from a test definition file. The name of the test definition file is test-def.props. The values in this property file only affect the current test. The format of this file is the usual name-value pair property syntax as:

  [Head] = value1 = value2

.. ..

Just as in the case of global configuration, each parameter can either be a literal string or a string representing a command to be uated. If the value is a command string as in the case of Results.file, then it is evaluated as though it were an actual ruby command. For example, in case of Results.file, the actual value may look like 050909_results.html.

The following properties can be defined for a test:

  • Object repository path - The path to the XML Object repository.
  • Results logger - You can direct the test to use a custom results class or the default text reporter.
  • Results path - Path to save the results to
  • Testdata path - Path to the excel file that is expected to serve as the datatable.
  • Testdata iterations - Number of iterations to run the test for. This could either be ‘1’ or ’*’. A
      value of 1 indicates that the test should only be run once. In this case the onus of choosing
      items from the datatable lies with the tester.
      A value of '*' indicates that the test must be run for all categories of the datatable.
  • Object identification timeout - The timeout in seconds to declare an object as not ‘findable’.

*Transaction specific parameters - You can have one ore more Transaction specific paramters defined in the test definitions. Depending on the number of transactions, you should define parameters as:

 name = blah



… and so on.

NOTE: Typically, one will not have to use this class directly. It is done automatically by the parts of WET which are responsible for executing the tests. However, if there should be any need, a tester can access the singletone instance of this class by saying



Included Modules



name  [R]  Get the name of this test. The name is defined as:
  name = MyName

Public Instance methods

Get the description of this test. The description of a test is in the test.defs file as:


Get the current iterations’ count. This is useful when the test definiton has been set to run on all iterations. During the course of the test, you may periodically want to log the current iteration being run.

This method is used to do a minimum load. In some cases, you may want to write scripts without using test definitions and wet runner. If this is the case and you still want to take complete advantage of WET’s advanced features, you will have to initialize the TestDefinition class, at least to its barebones level.

Accepts one parameter repo_path, which is the full path to the object depot file.

  An example of such a script is:

  require 'WET'
  include WET
  .... ('mypath')

to find objects. The object search fails only after waiting for this amount of time.

The syntax for defining this parameter is


Return all the transactions as an array of ‘precondition’ Hashtables. A test can have any number of preconditions defined in it. Each precondition is a reference to a ‘callable test’ (aka library test).The syntax to define a precondition is:

 name = P1
 path = ../testlib/add_user
 param1 = FirstParameter

An example of using the preconditions method is:

    p_all = TestDefinition.instance.preconditions
    pre1 = p_all[0]
    name1 = pre1["name"]

Get the full path for the results. This is used by the test runner to save the results after completing tests. The property to define the results path in the test definition file is:

results.path = ./results/

Return all the transactions as an array of ‘teardown’ Hashtables. A test can have any number of teardowns defined in it. Each teardown is a reference to a ‘callable test’ (aka library test).The syntax to define a teardown is:

 name = Td1
 path = ../testlib/del_user
 param1 = FirstParameter

An example of using the preconditions method is:

    td_all = TestDefinition.instance.preconditions
    td1 = td_all[0]
    name1 = td1["name"]

Return all the transactions as an array of ‘transaction’ Hashtables

A test can be divided into multiple transactions. Each transaction is associated with a name, path and any number of transaction parameters. The syntax to define transactions is:

 name = T1
 path = ../scripts/test.qws
 param1 = FirstParameter

 name = Second_Transaction
 path = ../scripts/another.qws
 param1 = test_value
 param2 = my_passwd

An example of using the transactions method is:

    t_all = TestDefinition.instance.transactions
    trans1 = t_all[0]
    name1 = trans1["name"]

WET is a opensource automated web testing tool which uses Watir as the library to drive web pages. WET drives an IE Browser directly and so the automated testing done using WET is equivalent to how a user would drive the web pages. WET extends the scripting abilities of Watir and also offers the convenience of recorders. It is licensed under LGPL and BSD style open source licenses.

Search powered by Google