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

API Guide - Main

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      

Top level API

Main module for the toolkit. This is the main interface to the outside world. This module has methods that act as wrapper to the different Object oriented libraries of WET, thus allowing the tester to use an object oriented script without having to get too deep into actually creating these objects. This allows the tester to create WET scripts that are simple and do not have too many class instantiation statements. # For example, to actually create a Browser class, you need to first instantiate a new Browser object, then call its attach method to attach it to a running instance of IE. However you can avoid the complexity of instantiation/initialization and directly call the ‘Browser’ method in this class. The code looks as simple as:

    Browser("param:=value")

Likewise to use the reporter object to write custom reports, you simply can say:

       reporter.ReportGeneral("This is a sample report")

Methods

Public Instance methods

Attach a running IE Browser to the test.

Arguments - Currently you can only specify title or url. The argument is specified as a named argument - either "title:=blah" or "url:=blah"

Detailed documentation about the Browser is found in the Browser class documentation.

Repository(name, *args)

Alias for object_depot

Call another script from within a running script. The called script Must be a WET Script (that is, a directory with a valid test.defs in it). The Test definition must have a root transaction defined, that is, the script.path=<xyz> must be defined, where <xyz> points to a ruby script This is usually used in preconditions / teardowns. When this method is called, It first unloads the current test definition, then loads the new test definition that is passed as the first parameter. After this the root transaction of this test definition is executed. The remaining arguments to this script become the transaction parameters for the

 called script.

Get the datatable instance for the current test run

The concept of datatables is used to test more than one set of data for the same test scripts. For example if you have a script that tests registration, then you can test the script for different categories of data without having to rewrite the scripts for each test. The most common way to use datatables is to retreive data from a table or spreadsheet.

The Datatable class documentation gives you complete details about the methods that can be used for a datatable

Execute a command in a separate process. In some cases (usu. when a modal dialog is opened), the current process waits for ever (or till the dialog is closed). In such a case, execute the command in a separate process so that the current thread is not blocked.

Note: In most cases you should not have to call this method explicitly Various methods in the WET module call this to accomplish tasks that are actually blocking, without actually blocking the whole test from running

The XML Object repository is a repository to store definitions for Hierarchy based object models. For example The Link "Gotogoogle" could be appearing on a browser with the following hierarchy - Browser(..) -> Frame(name=left) -> Table(…) -> Link. Then using the XML Repository, the Link will be represented using XML such that the hierarchy is same as above. This xml representation for the link should have a unique name in the repository (say Lnk_Google).

When this method is invoked as Repository(Lnk_Google), the actual Link object (if appearing on the page)

arguments:-

  • name - Name of the object in the object repository
  • args - one or more optional parameters. In the object repository

you have the option of specifying literal property values or ‘parametrized’ values. In case of the later, you would specify #${$qr_param1}, #${qr_param2} and so on. At run time qr_param1 is substituted with the first parameter, qr_param2 is substituted with second parameter and so on.

returns A subclass of WebObject, if the object can be identified at runtime or a WebZombie class if the object cannot be identified.

Get the results logger for the current test run

WET comes with an improved results logging mechanism. The actions and results for a test are written to a separate HTML file, thus providing a view of the sequences and consequences of the test alone rather than having to extract out information out of the entire console output.

For detailed documentation about the abilities of the reporter check the documentation of the Reporter class

Return the time at which the first test started. This is typically useful, if you want to publish results based on the time at which the tests (from a batchrunner) started off. Time is returned as an instance of Time class.

Get the transaction paramter for the current transaction. param is an integer corresponding to the nth parameter that needs to be retreived.

WET has the abilitity to define tests a test definition file. Each test can define any number of transactions. For each transaction itself, you could define any number of transaction parameters. Sometimes the outside world calling the test needs to pass parameters to WET. This is achieved by defining transaction parameters

Use the following method to retreive any predefined parameter for a transaction. For example, if your test definition (fragment) looks like … … [Transaction2] name = login_as_admin path = ./scripts/login_admin.wet param1 = superuser param2 = my_pwd .… .…

Assuming that the current running transaction is Transaction2, invoking get_transaction_parameter(2) will return ‘my_pwd‘

The TestDefinition class documentation describes each of the testdefinition parameters in detail.

 

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.

WWW wet.qantom.org
Search powered by Google