Speaking Name

The value shown in the Element column of the editor table can be meaning less. The Speaking Name can be used to set a meaningful value. The Speaking Name is stored as an attribute of the GUI element in the MyITest4U database and will be shown each time this Web element is used. The Speaking Name can also be set in the search result table of a Web element search.

Web Drivers

Web drivers can be added under Run / Drivers (an AUT needs to be selected).

Name The driver name has to be unique.
Property Name The name of the property which sets the driver exe.
Java Class Name The java class which is instantiated when the web driver is used.
Exe Path to the driver exe.
Option Selenium allows the use of different driver options. Option needs to be set to a value (any value can be used) to use driver specific options. If no value is set no options will be used for this driver.
The driver options to be used have to be defined in the class WebDriverOptions (see Eclipse Project ). The option value can also be used to distinguish between different options in the class WebDriverOptions. Driver options are not user specific.
Default The default driver to be used. A different default driver can be set for every AUT.

Profiles

Profiles can be set under AUT / New AUT or Update AUT.

In a profile the root and page URL of the AUT can be set.

A profile can be public or private. A public profile can be seen and edited by all user. A private profile is only visible for the user creating the profile.

Each user can set a default profile. The default profile is used after setting the AUT if no other profile is set. If no default profile is set the first profile in the profile list is used.

Parameter Files

Parameter files are stored in the following folder:

...\MyITest4U\AUTReleases\<AUTRelease>\ParameterFiles

Parameter files contain all test parameters and check points. Each line in the parameter file represents one loop.

An empty line will stop test execution.

Comments can be added below the parameter lines. Make sure there is at least one empty line between the last parameter line and the comment.

The parameter file has the following basic structure:

Step 1;Step 2;.…;Step N

Each parameter has a section for values, index, Find, NotToFind and AP (additional parameters).

Step 1;Index;Find;NotToFind;AP;Step 2;Index;Find;NotToFind;AP;....

The Step i column contains the parameter values.
Index is the index of the GUI element. The default is 0 (counting starts at 0).

Find is a string which needs to be found on the current page (the source of HTML page is used e.g. the method getPageSource() of the class WebDriver is used to obtain the source of the HTML page).
NotToFind should not be found on the current page.
Both Find and NotToFind can contain more than one string. They need to be separated by "|". Escaping of "|" can be done as shown in the following example:

aaa|fff\|bb\\||b

results in

aaa
fff|bb\|
b

Additional Parameters (AP)

Addition parameters can be set in the AP field by the use of a string containing the letters i, x, t, s, y, z and a positive integer. The integer stands for StepsToGoBack. Its default value is 0. StepsToGoBack is mandatory. The letters are optional. The order of the integer and the letters does not matter e.g. st1 or s1t have the same meaning. Each additional parameter is described below.

StepsToGoBack

StepsToGoBack has to be a positive integer between 0 and the total number of test steps.

StepsToGoBack can be used for a retrial of a test part like the filling of a form. The test needs at least two loops. The test will run in the first loop till StepsToGoBack is > 0. Than will go back the given number of steps and continue with the second loop. Steps which are done are marked green in the editor. Steps which are not done are marked white. Check boxes on a white line might not be checked as they are meaningless anyway.

In the last loop StepsToGoBack has to be 0 for all steps.

StepsToGoBack can not be set for an ignored step. StepsToGoBack will be ignored if it is set together with ignore step.

An example where stepToGoBack is useful, is the checking of a parameter validation as shown in the following example:

The AUT has an address form. Step 1 - 10 are needed to get to the address form. Step 11 - 15 will fill in the address data. Step 16 will submit the address form only if all fields are filled in correctly. Step 17 - 24 will do something with the address data.
In loop 1 the test runs till step 16. In the step 11 - 15 invalid address data was added.
Loop 2 will start at step 11 fill in the correct address data and run till step 24.

Further Additional Parameters

The further additional parameters can be inserted after StepsToGoBack. They are:

i i indicates that this test step should fail and the error will be ignored. A working test step which is marked with an i will result in an error with the text ShouldNotWork. The use of the i allows doing negative tests which will not show up in the test result as error. Further it allows to mark test steps which should work but do not because of a bug in the AUT. Once the bug is fixed the test result will indicate the change and the i can be removed.
x Steps marked with x are ignored. The x is useful in combination with test templates e.g.
For all parameter validation the same test template can be used. Parameters which are absent can be marked with x and so the same template can be used for all parameter validation. Doing a parameter validation in this way leads to less tests.
StepsToGoBack for steps which are ignored (marked with x) has no effect.
t A screen shot is taken after a step which is marked with a t.
s All GUI elements of the current window are collected if a step is marked with s.
a Analysis of browser logs can be ignored with an a.
j Analysis of JavaScript exception can be ignored with an j.
y Global Find can be ignored with a y.
z Global NotToFind can be ignored with a z.

a, j, y and z can only be set in the parameter file. They never show up in the editor.
The use of Global Find and Global NotToFind is described under Universal Check Points.
The use of Analysis of browser logs and Analysis of JavaScript exception is described under General Configuration.

Best Practice

The Parameter File is written after saving a test / test block. The "old" content is moved to the comment section of the Parameter File. Therefore it is best to finish a test / test block and then edit the Parameter File.

Java Script Alerts

Java script Alerts are NoGuiElements. They can not be analyzed by Selenium.

Therefore you have to use NoGuiElement for URL, Tag and Element. Then you can select the desired action.

The default waiting time for an Alert to appear is 10 seconds. It can be changed using a positive integer as first parameter in an Alert action. In case of an error the default waiting time is used.

Browser logins are made using the Java Robot class. The browser login from MyITest4U can not check for the presence of the login screen. Username and password will be entered in the actual active window. So please make sure that really the login screen is active when you use the AlertSetCredentials action.

Frame And Window Handling

Frames can be spidered or not by setting the appropriate check mark in the Spider Configuration.

Switching to a certain frame should work automatically.

GUI elements of a window are collected but windows are not spidered.

The switching to a certain window needs to be done using the SwitchToWindow action.

The action SwitchToMainWindow will switch to the main window.

Cookies

Selenium has methods to handle Cookies. MyITest4U has the following actions which can be used to handle Cookies:

  • CheckNamedCookie
  • CreateCookie
  • DeleteAllCookies
  • DeleteNamedCookie
  • SetCookies
  • WriteCookies

The first four actions are self-explanatory.
WriteCookies action writes all Cookies to the file cookies.txt in the folder containing the Parameter Files.
SetCookies action sets the Cookies using the information contained in the file cookies.txt.
cookies.txt contains the following values separated by ;.

  • name
  • value
  • domain
  • path
  • expires (Date)
  • isSecure (boolean)
  • isHttpOnly {boolean)

The values are the ones obtained with the respective methods of the Cookie class provided by Selenium.
null is set for the domain localhost.
SetCookies uses SimpleDateFormat("dd MMM yyyy hh:mm:ss z", Locale.ENGLISH) to read expires. null is used if expires can not be parsed to a Java Date.
Boolean.valueOf(<...>) is used to transform isSecure and isHttpOnly to a boolean.

Selenium allows the setting of Cookies only after a page is called. MyITest4U always starts a test by calling the Page URL. The first step in a test can therefore be SetCookies.

Many Web pages show a Cookies information on their first page.
MyITest4U can deal with the Cookies information in the following ways:

The action WriteCookies can be used to store the Cookies belonging to the Cookie information.
The action SetCookies can be used as first step in every test. The action GoToStart has to be the next one in case the Cookies information blocks the use of the Web page.

The Selenium Web Driver Option options.addArguments("--user-data-dir=<directory where the information is stored>"); can be used to store all data produced by the Web page. In this approach the Cookies belonging to the Cookies information have to be stored only once and no additional test step is needed.

The described approaches can also be used to deal with Cookies used in other situations like "User login" etc.

Universal Check Points

As mentioned above MyITest4U can compare the test run against a reference. The reference can be the visible text of the webpage or the source code of the webpage. Post Proc Action is used to define after which actions the comparison is done. The default is Click.

Strings that will always change can be defined in the AUT Information and Configuration dialog using the Will always change field. The string separator is |. These strings are excluded from the comparison. Technically, this is done by replacing the defined strings with an empty string in the reference. Will Always Change can be used for things like release names, which will be different for each release.
Strings that will change in each test run, such as current time and date, are handled by filters.

This type of test is set up in the following way:

Open the Run Configuration (Run / Run Configuration).
Check Do Analysis and select Save HTML source or Save text only.

Create the reference

Run your test the first time to create the reference.
Run your test a second time to create filters for always changing text, such as current time or dates.

Run your test against the reference.

The third and subsequent test runs perform a comparison against the reference.
This is done by making a line-by-line comparison. Each time there is a difference, an error will be shown.
Using Visible Text (Save text only) in the comparison will usually work fine and will only show real changes.
Using HTML source in the comparison will be very sensitive as even a small change in the formatting of the source will produce an error.

The MySaveAndCompareHTML class (com.myitest4u.selenium.api.saveAndCompareHTML) can be used to define your own comparison.

The reference is saved for an AUT release. The reference needs to be copied manually from one release to an other one.

The following entries are shown in the error tooltip in case MyITest4U finds a difference.

Reference Shows the text of the reference
Run Shows the text of the test run
Raw Difference Shows only the differences found and line numbers
Difference Shows the two files in the configured tool to show differences (usually WinMerge)
Move Run Moves the run files to the reference

Screen shot labels are set in the same way.