Tips and tricks for functional testing HTML applications
This topic provides tips and tricks for recording and playing back scripts to test HTML applications.
Start recording first and then start the application
When recording scripts on your HTML applications, useHCL DevOps Test UI (Test UI) to start the application during recording.Test UI opens the HTML page that you specify in your default browser or in a specific browser.
Recording a hover on HTML menus
When recording scripts on your HTML applications, you can record a hover on drop-down menus that are activated when you roll the mouse over the drop-down menu. These drop-down menus are implemented with DIV tags. To record a hover for drop-down menus, and make the sub-menu drop down, hover the mouse over the menu item text and press Shift. Make sure the mouse is on the text of the menu item and not on the blank space to the right of the menu item text.
Use deleteCookies method in your scripts
Two versions of the deleteCookies method are available. One method deletes all cookies for the current profile or user and the other method deletes cookies in a specific path or domain for the current profile or user. For information, see theTest UI API Reference, in the com.rational.test.ft.object.interfaces package, under IBrowserObject. See https://www.ibm.com/support/knowledgecenter/SSJMXE_8.6.0/com.rational.test.ft.api.help/ApiReference/com/rational/test/ft/object/interfaces/IBrowserObject.html?lang=pl.
Avoid including menu items in scripts
Because selections on browser menus are recorded based on their screen coordinates, scripts may not play back reliably if the browser size or position change. Also, menus are different on different browsers, which may also cause scripts to play back incorrectly.
Make sure Java applets are in full view during playback
If you resize the browser to a smaller size,Test UI does not scroll the applet objects into view during playback if they are not in view.
Use the loadURL( ) method to change URLs
The location of the Address field in a browser is based on screen coordinates, which can change if the browser's size and position change. A script usually fails if you click in the Address field and type the new URL. When recording, insert a browser click (Browser_htmlBrowser) in your script to change URLs.
- When recording, click any empty space in the browser header to include a browser click in your test object map.
- After recording, view the script and place the cursor on a blank line in the script.
- In the Script Explorer, expand Test Objects, right-click Browser_htmlBrowser, and select Insert Asset at Cursor.
- Select the
loadURL(String)
method. - Type the name of the new URL between the parentheses of the
loadURL
statement. - Insert a semicolon (;) at the end of the line for only Java™, and not for VB.NET.
Using .size property for INPUT elements
If you use .size Property for INPUT elements and do not specify the .size property within the Html of an INPUT element, the default value returned by the Internet Explorer is 20.
Use toolbar buttons common to both browsers
When you create a cross-platform script, avoid toolbar buttons that only appear in one browser. The following toolbar buttons are common to both browsers:
- Back
- Bookmarks /Favorites (Internet Explorer)
- Close
- Forward
- Home
- Maximize
- Minimize
- Search (button only)
- Stop
Use the close button to exit a browser
The Close button is available in the Internet Explorer. When you record a cross-platform script, avoid using alternative methods of exiting the browser. For example, pressing Alt+F+C works only for Internet Explorer. Either key combination causes a script to fail when run on the other browser.
Check the .readystate of the browser object
Sometimes script playback for testing HTML application fails if the ready state of the browser object is not 4. Ensure that the ready state of the browser is 4 while playing back a script. You can do this by modifying the test script manually as shown in the examples.
Script to
check the browser state in Java™: logInfo("Ready
State #: "+browser_htmlBrowser().getProperty(".readyState").toString());
Script
to check the browser state in .Net: LogInfo("Ready State #:
" & Browser_HtmlBrowser().GetProperty(".readyState").ToString)
Use waitForExistence method to compensate for browser startup speed
Use a waitForExistence method when recording cross-browser scripts to wait for a browser. For example:
- When recording, start the application.
- Click the Insert Verification Point or Action Command button on the Recording toolbar.
- In the Select an Object page of the Verification Point and Action Wizard, click the Object Finder icon and drag it over the HTML page (not the browser itself).
- Click Next.
- In the Select an Action page of the Verification Point and Action Wizard, click the Wait for Selected TestObject option.
- If necessary, clear Use the defaults to change the Maximum Wait Time and Check Interval settings, which are 2 minutes and 2 seconds, respectively.
- Click Finish.
Avoid these click and key combinations in cross-platform scripts
To handle a pop-up menu, some browsers ignore a click action on a link immediately following a right-click. When this click combination is necessary, right-click the link, click an empty space in the document, and then click the link.
In some browsers, pressing Ctrl and clicking a link opens the page in another instance of the browser. This same key sequence results in a normal link click in other browsers. A script that contains this combination of actions plays back differently and should be avoided for cross-browser testing.
Run a utility to fix badly formed HTML
Occasionally errors in HTML can cause different browsers to interpret the HTML DOM hierarchy differently. A script that runs successfully in one browser can fail in another. Record one script against each browser and compare the resulting test object maps. If the maps show a different hierarchy, run a utility, such as HTML Tidy. If the utility reports errors, it is possible that the errors are causing the different interpretations of the object model, resulting in different hierarchies. HTML Tidy is available from the World Wide Web Consortium, www.w3.org.
Handling pop-up message boxes
When recording a script in some browsers, a pop-up message (browser user interface dialogs), such as encryption notices occasionally appear. When recording a cross-browser script, you do not want to include these message boxes, because they may not appear in other browsers. To avoid this problem:
- When a pop-up message appears, pause recording.
- Select any check box on the message that prevents the message from appearing again.
- Click Cancel to close the message box.
- Resume recording.
You can modify your script to handle these kinds of message boxes, but the code can be complicated. For more information, see the ExtendingTest UI functionality topics.
When you record a cross-browser compatible (a script that is compatible across all browsers thatTest UI supports) script, try to avoid recording any pop-up message boxes. If you are not recording a cross-browser compatible script, you can record pop-up message boxes in your script.
Test UI supports the Login, File Download, Certificate/Security Warnings, File Picker (File Open/File Save), and Print dialogs on the Windows® platform. These user interface dialogs are for a specific browser and are not cross-browser compatible. In most cases, the Login dialog is cross-browser compatible.
Testing URLs without configuring the application
When you configure an application, Functional Test adds the application name to the Application Configuration Tool. If you test a lot of different URLs, the Applications list can become long. If you do not want to add a URL to the list, you can use the startBrowser command in an empty script to test it.
- Create a new functional test script without recording.
- On a blank line, type the following command:
startBrowser ("url");
- Save the script and run it.
- When the page is displayed, on the Functional Test toolbar, click Insert Recording into Active Functional Test Script and start recording against the page.
Testing HTAs
Test UI supports testing Microsoft® HTML Applications (MSHTA). Before you can test a MSHTA, you must configure it by running mshta.exe. To configure each HTA you want to test:
- In the Kind field of the Application Configuration Tool, select executable or batch.
- In the Executable file field, select mshta.exe.
- In the Args field, pass the parameter x.hta to the executable, where x is the name of the HTA file.
For more information, see Configuring Applications for Testing.
Handling Java plug-in errors
If an error about the Java™ plug-in is returned, when you test HTML applications or start the Comparator from the View Results link in the HTML log, you need to verify that your browser's Java™ plug-in is configured properly. For instructions, see the related topic about enabling the Java plug-in of a browser.