Defines the base url for all relative url's in your test scripts. Usually this is the url (and maybe the fixed part of the context path) of the machine/application under test. This property makes your tests independent from the server your application runs on.
It is possible to overwrite this property to use this configuration file for different stages (test, qa).

Wetator executes every test case for every browser defined by this property. The value of this property is a comma separated list. Possible values are:

• Firefox_38
• Firefox_45
• IE_11
• CHROME

Every browser send a special 'Accept-Language' header to the server to inform about the language preferences of the user. Usually this depends on the language setup of your operating system. But it is possible to define/overwrite this as part of the user setting of your browser. By setting this property you can fine tune the header to test special setups for users from different countries.

When uploading files the browser tries to detect the mime type submitted as part of the upload request based on the extension of the file. Every browser has a hard coded list of such mime types but, if the extension is not found, the browser interact with the operating system to determine the mime type based on the installed software. Use this setting to configure your simulated browser to e.g. detect MS Office mime types.

HtmlUnit supports ActiveX object mocks lets you simulate special plugins required for your application. For every AxtiveXObject (class) you have to write your own mocker java class and add it to the class path. For more details have a look at the HtmlUnit documentation.

The directory used to store the xml result file and all the page snapshots. This directory is also used for all the XSL Templates (see wetator.xslTemplates) as output directory.

You can use a relative or an absolute directory path. For relative paths, the path is relative to the location of the config file.
If the directory does not exist, Wetator will create it.

Set the property 'wetator.distinctOutput' to true if you like to have a distinct subdir for every test run.

After the whole test suite is processed, Wetator can execute xls transformations of the resutl file (xml) to produce nice reports.

This property holds a comma separated list of xsl templates files. TODO name

You can use a relative or an absolute files. For relative paths, the path is relative to the location of the config file.

If you want to test an application behind a proxy, set these properties.
wetator.proxyHost=[name or ip of the proxy]
wetator.proxyPort=[port]

Sometimes you have to not use the proxy for some host
wetator.proxyHostsToBypass=[list of host names separated by |]

and finally some proxies require an authentication
wetator.proxyUser=[proxyuser]
wetator.proxyPassword=[proxypassword]

If your application under test requires basic authentication, than you can define the user here.
wetator.basicAuthUser=[user]
wetator.basicAuthPassword=[password]

If your application under test requires NTKM authentication, than you can define the client info here.
wetator.ntlmUser=[user]
wetator.ntlmPassword=[password]
wetator.ntlmWorkstation=[password]
wetator.ntlmDomain=[password]

It is possible to extends the list of command by adding your own. Commands are grouped in CommandSets.
Two additional command sets are already availabale (as part of the wetator.jar):

• org.wetator.commandset.SqlCommandSet (commands for sql database access e.g. for setting up your testdata)
• org.wetator.commandset.IncubatorCommandSet (command not yet part of the default command set but you can use it to play with this)

Define all your command sets (classes) here as comma separated list.
There is no need to register the build in default command set (org.wetator.commandset.DefaultCommandSet) here.

The separator used for splitting the WPath into parts.

Default is '>'.

Sometimes some companies using additional web controls (usually plugins). Because Wetator is based on HtmlUnit, there is no easy way too support this plugins.
But you can write your own support for this based (e.g. a simulation of the features). This additional controls are handled the same way than any outer control.

Define all your control (classes) here as comma separated list.

Scripters are the way to support different input formats. Excel and (our) XML format are supported out of the box.

Define all additional scripters (classes) here as comma separated list.

The timeout in seconds Wetator will wait for JavaScript jobs to complete after the execution of an action.

This setting is optional; if not defined 1s is used.

Requires version 1.1

The name of the file that contains filter definitions for JavaScript jobs.
This feature is helpful for applications using some kind of heartbeat jobs (e.g. Vaadin). Usually Wetator will wait after each action until all JavaScript jobs are finished or the jsTimeout is over. The jsJobFilter let you exclude some jobs from this wait.

You can use a relative or an absolute directory path. For relative paths, the path is relative to the location of the config file.

The filter file syntax is quite simple; lines starting with '#' or empty lines are ignored. Every other single line defines a filter.

This setting is optional; if not defined no filters are active.

Example

You are testing a Vaadin app. Your result output contains many warnings stating "Still some JavaScript jobs pending".

 

Enable the use of a jsJobFilterFile in wetator.config

wetator.jsJobFilterFile = js_filter.cfg

Place an empty file named 'js_filter.cfg' in the same directory as wetator.config.

 

Add a filter definition to the filter file

1. Open your result output and locate the string representation of the pending job.

2. Copy the string into your filter file (js_filter.cfg).

3. Remove all line breaks (but do not remove any blanks).

4. Transform the string into a pattern by replacing dynamic parts like counters by '*'.

The filter uses the same simple pattern language as the commands ('*' and '?'). You are free to build more sophisticated filters by replacing more parts with these wildcards.

The timeout in seconds Wetator will wait for HTTP responses.

This setting is optional; if not defined 90s is used (same as real FF).

The simulated typing speed of the user in keystrokes per minute.

Sometimes every keystroke for an entry field triggers some javascript. Usually the javascript code was written and tested by real users and because of this writing from wetator at full speed might break this javascript event handlers.

This setting is optional; if not defined 200 (keystrokes per minute) is used.

This is for debugging only. If enabled wetator will write detailed logs for the specified number of steps before the error ocurs.

Enabling this requires log4j inside your classpath.

Enabling this will change the log level for org.apache.http.wire to TRACE. Take care that all your appenders for this logger have a proper threshold defined.

This setting is optional; if not defined -1 (disabled) is used.

Variables are defined as part of the configuration.
The definition starts always with a '$' sign.
You can refer to this variable from all command parameters with the expression ${var-name}

Examples

  $title=My Title
  $app_user=dobby

  $app_user=dobby
  $$password=secret

It is possible to define or redefine variables based on system properties. After reading the variables from the configuration file, Wetator detects all system properties starting with '$'. If there is already a variable (defined from the configuration file) it will be overwritten, otherwise the variable will be added.
If you are not sure about the current setup the report list the actual state of all defined variables.

VM argument
-D$title=SpecialTitle