Dashboard > WET > Using test libraries with WET
WET Log In View a printable version of the current page.
Using test libraries with WET
Added by Sathya Shankar, last edited by Raghu Venkataramana on Sep 29, 2006  (view change)
Labels: 

WET has advanced features that lets you reuse test repositories. On this page, we'll see how to reuse the following three test artifacts:

1) Test libraries
2) Common tests
3) Global precondition

Before, we see these in detail, please remember that a well organized test folder will help your automation effort in terms of both creating and maintaining. An example is as shown below:
<MY_TEST_DIR>-- lib
        |-- etc
        |-- doc
        |-- common_actions
        |-- scripts
        |-- data
        |-- repository

Test Libraries:
By test libraries, we mean ruby scripts that you write to assist the automation of your application. If you were to follow the directory organization suggested above, then you'd put all of your library scripts in the 'lib' directory. In order for your test scripts to be able to use one or more files from the library, you need to specify the library path in the global configuration file. The global configuration file is a config file that is stored in %QWT_HOME%\etc\global-config.cfg. This file has a (commented by default) section:

===========
[Include]
###either provide a single file or directory listing or a directory
###from which all script files should be included
#
#path=C:/wet/samples/SampleScript;C:/wet/samples/sandbox

###Pattern of known script files - syntax - *.a or *.
{a,b,c}
##
pattern=*.
{rb,qws}
#test=#
{ENV['tests']}/common_precondition
===========

In the above lines, replace the #path parameter with:
path =/lib/lib_file1.rb;/lib/lib_file2.rb;...;/lib/lib_fileN.rb
OR
path =/lib/
Where lib_file1.rb, lib_file2.rb, etc are the ruby files that you want WET to use at runtime.

If you want WET to load all the files in the lib directory, then simply choose the second option - specify path as a directory rather than file name(s). In case of the latter, all files matching the value specified by the pattern parameter are loaded.
After you specify the libraries, you can then call classes and utilities defined in your libraries anywhere from your test scripts.

Common tests:
Common tests are somewhat similar to libraries. However these are actually full tests by themselves (but without any transactions). I will use the terms common tests, action tests / library test interchangably. In the test definitions' Common section, you will find a snippet that looks as follows:
## 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

The script.path is the path of a qws script that will be run if this wet test is called from another script. The transactions in this test definition will be ignored - in fact you should not define a test definition which has both transactions and script.path in it. Other than not having transactions, everything else about a 'library' test is the same as a regular wet test script. To invoke an 'action' test from any other test, you use the function:

call_test(wet_test_path, [array_of_parameters])

where, wet_test_path is the path where your library test resides.
array_of_parameters are optional transaction parameters that are passed to the script.

An example library script is as follows:

###############
# Action for Logging into the server
# Date : 04-30-2006
# Author : Raghu Venkataramana
#
# This.filename = login.qws
### signature - login_server(userid, passwd)
######################
userid = transaction_parameter(1)
passwd = transaction_parameter(2)

ie=Browser.new()
ie.goto('www.example.org/login')
Repository("TF_Login_Username").set userid
Repository("TF_Login_Password").set passwd
Repository("Btn_Login_Submit").click
Repository("Lnk_TopFrame_Home").check_exists()

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

For the above test, the test definition may look like:

[Common]
name = login
description = This script opens a new browser, navigates to the example server and then logs in
repository.path = eval #
{ENV['MY_TESTS']}
/repository/all_objects.xml
lib.path=eval #{ENV['MY_TESTS']}/lib
script.path = ./login.qws
================================================

Now from any of your other tests, you may say:
call_test("#{ENV['MY_TESTS']/common_actions/login", ["dummy_user", "12345"]})

Global precondition:
Another fantastic feature of WET is the ability to define global preconditions. Many a time, you'd want to run one common set of actions before you start any test. Instead of definining this as a precondition for every test, you can just specify that you want to run this as a global precondition. Then before any test is run, this global precondition is called. An example is to make sure that before starting all tests, you first close all open browsers, then log into your server, check that the home page is being displayed and only then proceed to doing other actions.

To define a global precondition, you will need to define the 'test' parameter (under Include section) in the global configuration. In the ENV['QWT_HOME']/etc/global-config.cfg file, you will find a commented entry:

Include]
...
...
#test=#{ENV['tests']}]}/common_precondition
Uncomment the entry and make it to point to your common precondition's path.

Site running on a free Atlassian Confluence Community License granted to OpenQA. Evaluate Confluence today.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.5.6 Build:#812 Aug 06, 2007) - Bug/feature request - Contact Administrators