Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

How can SilkTest test Web Pages with different possible start-up DialogBoxes or Pages?

How can SilkTest test Web Pages with different possible start-up DialogBoxes or Pages?

Sometimes a web page may have a different startup page depending on when the user logs in, who is logged in etc. An example of these may be;

  • A Web application requires the user to login the first time they visit the site in a day (a non-persistent cookie). If they"ve already logged in for this browser session, they won"t be prompted for user name and password again. This could be either a login Web page or a DialogBox.
  • There"s a DialogBox that sometimes gives a "tip of the day" or reminds the user to perform some action because it"s a certain date.
  • A DialogBox might popup asking the user whether or not it"s okay to download a certificate, a Java module, or some other component.

While testing client-server applications SilkTest has built-in recovery system components for dealing with objects such as these (the wStartup data-member); when working with Web pages it is a bit more challenging, as there is no easy way to deal with them.

The Recovery System
As we already know DefaultBaseState works with the wMainWindow object in the following way:

  1. If the wMainWindow object doesn"t exist, Invoke it, either using the Invoke method defined for the MainWin class or a user-defined Invoke method built into the object. If wMainWindow is a BrowserChild object and the browser isn"t loaded, load the browser before loading the Web page into it.
  2. If the wMainWindow object is minimized, restore it. If wMainWindow is a BrowserChild object and the browser is minimized, restore it.
  3. If there are child objects of the wMainWindow open, close them. If wMainWindow is a BrowserChild object, close any children of the Browser.
  4. If the wMainWindow object isn"t active, make it active.
  5. If there"s a BaseState method defined for the wMainWindow object, execute it.

The challenge with this process, in this situation (where a DialogBox or a different Web page loads on request), is in step 1 of the recovery system: when attempting to load the Web page, the recovery system expects that Web page to be loaded. And it might not be if a Login page sometimes loads first for the user to enter information into. Or, if the page does actually load but a DialogBox appears over it, in step 3 of the recovery system the DialogBox will be closed in the most efficient way without any regard for actions that may need to be taken, such as clicking OK.

Login Web Pages
This is perhaps the most common problem that users have. In many Web sites, the user is issued a non-persistent "cookie" (meaning that it disappears as soon as that instance of the browser is shut down) when they login. When they return to the site in the same browser session, they will not be prompted to login again, as their "cookie" is still available with their authorization. For SilkTest, this means that trying to load the actual Web page will sometimes not work as the login page appears.

The easiest way to deal with this problem is a bit unorthodox, but not as unorthodox as modifying the recovery system files directly - which is always a bad idea (since the files will be updated in the next product release). When the DefaultBaseState wants to load a Web page, what Web page does it decide to load? wMainWindow is, of course, the Web page, but it then retrieves the sLocation data-member from the wMainWindow object, which should be the URL for that Web page. However, there"s another way to use sLocation: as a property.

The property that has been created will look exactly like a data member and can be called in the same way. The property could be created in whichever way is required and have additional verification such as how to deal with login pages as shown above.

The following steps will be taken now when the DefaultBaseState is called:

  1. DefaultBaseState will try to retrieve the sLocation data-member and, as such, will execute the Get function.
  2. The Get function that"s part of the property will actually load the Web page by putting the URL of the page into the Location ComboBox that is part of the Browser and hitting Enter. It will then wait for the Browser to report to SilkTest a ready state.
  3. If the Login page exists - rather than the page we were expecting - the user name and password will be entered and the HtmlPushButton OK will be clicked on. Again, SilkTest will wait for the Browser to return to a ready state.
  4. The Get function returns a NULL even though at the definition of the Get function it was specified that a STRING would be returned. If you were to return, the URL DefaultBaseState would load the page again but as this has been already dealt with there is no need.
  5. Although DefaultBaseState will not try to load the page, it will find it there and continue with the other steps of closing any open windows and setting the browser and Web page active.

Old KB# 21800

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
1 of 1
Last update:
‎2013-02-15 19:24
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.