How to Automate Native Browser Dialogs, ActiveX, and more

Squish is primarily designed to support the automation of operations on web pages' DOM, DHTML, and HTML elements. But to completely test a web application, it is often necessary to automate operations on other kinds of component, and also on dialogs—this section shows the techniques used to perform such testing.

Automating native browser dialogs (login, certificates, etc.)

Many web applications require a login using the browser's native authentication dialog, or the acceptance of certificates as part of the startup process. Squish makes it is possible to automate logins and the acceptance of certificates as described below.

Automating a native login

Squish provides a function, automateLogin(username, password), that you can call from your test scripts to automate a login with the browser's native authentication dialog. The key to using it is to start the login process (typically by clicking a button or link), then wait for the login dialog to appear, and then enter the username and password. Here's an example snippet that shows how it might be done:

clickLink(":Login_A")
waitFor("isBrowserDialogOpen()")
automateLogin(tester_username, tester_password)

clickLink(":Login_A");
waitFor("isBrowserDialogOpen()");
automateLogin(tester_username, tester_password);

clickLink(":Login_A");
waitFor("isBrowserDialogOpen()");
automateLogin($tester_username, $tester_password);

clickLink(":Login_A")
waitFor("isBrowserDialogOpen()")
automateLogin(tester_username, tester_password)

invoke clickLink ":Login_A"
invoke waitFor {invoke isBrowserDialogOpen}
invoke automateLogin $tester_username $tester_password

The snippet assumes that tester_username and tester_password are variables that hold the tester's username and password.

In some cases there is no such Login button or link, instead the login dialog is opened up automatically while the website starts to load. This use case needs a slightly different approach when this website is being loaded with the startBrowser(url) function.

Squish ensures the website given to the startBrowser function is loaded before returning from it to the test script. While the browser shows the login dialog the loading of the website will be paused and not proceed until the dialog has received the proper login data. This is a problem since the automation of the login can only happen once the startBrowser function has finished and the following automateLogin invocation is being executed. So the test will eventually hang until startBrowser runs into its timeout and generates an error.

In order to make this use case work, it is necessary to load an unprotected website first such that startBrowser can finish successfully. Once startBrowser is done you can use evalJS() to set the location.href property of the JavaScript window to load a different website. Setting the property returns immediately before the page is fully loaded even if the website opens the login dialog. The following snippet shows a small example code that handles this scenario:

startBrowser("https://www.froglogic.com/");
evalJS("window.location.href='https://secureweb.site';");
automateLogin(tester_username, tester_password);

startBrowser("https://www.froglogic.com/")
evalJS("window.location.href='https://secureweb.site';")
automateLogin(tester_username, tester_password)

startBrowser("https://www.froglogic.com/");
evalJS("window.location.href='https://secureweb.site';");
automateLogin(tester_username, tester_password);

startBrowser("https://www.froglogic.com")
evalJS("window.location.href='https://secureweb.site';");
automateLogin(tester_username, tester_password)

invoke startBrowser "https://www.froglogic.com"
invoke evalJS "window.location.href='https://secureweb.site';"
invoke automateLogin $tester_username $tester_password

Squish's automateLogin(username, password) function automates the native browser authentication dialog for any of Squish's supported browsers, so you don't have to make any allowances for browser differences yourself.

ActiveX

Squish can automate interactions and test non-HTML/DOM elements, that is, native objects, which are embedded in a web page. This is done at a fairly abstract level, which means that mouse and text input can be recorded and replayed. In addition it is possible to inspect embedded native objects with the Spy tool and to insert verifications for these native objects. All of a native object's public properties can be accessed in test scripts.