Opensource automated web test tool

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]
  prop.name = value1
  prop2.name = 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:

 [Transaction1]
 name = blah

 [Transaction2]
 name=more

… 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

TestDefinition.instance

Methods

description iteration_count load_minimum object_timeout preconditions results_path teardowns transactions

Attributes

name

[R]

Get the name of this test. The name is defined as:

  [Common]
  name = MyName

Public Instance methods

description()

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

   [Common]
   obj.timeout=10

iteration_count()

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.

load_minimum(repo_path)

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
  TestDefinition.instance.load_minimum(or_path)
  object_depot('something').some_operation
  object_depot('someother').next_operation
  ....
  reporter.save ('mypath')

object_timeout()

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

The syntax for defining this parameter is

  [Common]
  obj.timeout=10

preconditions()

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:

 [Precondition1]
 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"]

results_path()

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:

Common: results.path = ./results/

teardowns()

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:

 [Teardown1]
 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"]

transactions()

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:

 [Transaction1]
 name = T1
 path = ../scripts/test.qws
 param1 = FirstParameter

 [Transaction2]
 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"]

API Guide - WET Test Case

Methods

Included Modules

Attributes

Public Instance methods