Testing Complex Web Applications With Siesta

Testing large web applications can be tricky sometimes. With advanced user interfaces containing animations, expanding and collapsing sections and load masks, there are many things that can make a test break. Sporadically failing tests can be very painful to deal with, usually caused by hidden race conditions that are hard to locate. Effort needs to be put in to making sure the test always produces the same result. If a test fails a certain percentage of the time when run, it should be refactored or deleted as it’ll just produce noise which distracts you. In previous versions of Siesta, you had to take care of these race conditions yourself, and add waitFor statements where needed if a target wasn’t immediately clickable. In the latest Siesta release 3.1.0 released today, we’ve implemented a new targeting strategy which is much more tolerant of unstable DOM targets – targets that move or are temporarily inaccessible.

Dealing with an unstable DOM

We decided to add a few “pre-action” steps before DOM interactions to verify that the targeted DOM element is stable. The strategy is outlined below:

1. 1. Wait for target to be present and visible in the DOM
2. 2. Scroll it into view if needed
3. 3. Move the cursor to the target, and after moving make sure that the target didn’t move.
4. 4. Wait again for target to be present, visible and reachable, not obscured by other DOM elements above it with higher z-index.
5. 5. If target has moved, or is not reachable, sleep for 100ms and start over.
6. 6. All is fine – perform the click or drag operation etc.

This sequence will simplify your testing a lot and help you avoid unnecessary and tricky race conditions. To demonstrate Siesta’s new capabilities, let’s go through a few different common application scenarios.

Clicking a button that is temporarily unreachable

Typically web applications deal with a lot of data. During loading it’s a common practice to disable certain UI controls during load/save operations. Below is a sample image showing such a UI panel:

As you can see there is no way to click the button before the loadmask has disappeared. Siesta will now wait until the button becomes accessible and then click it. In previous versions you had to take care of this yourself and insert waitFor statements yourself before issuing the click command.

Clicking a UI element that appears after a delay

Another interesting scenario is interacting with UI elements that are not initially in the DOM. Siesta will now wait for the target to appear before interacting with it, again saving you from the pain of adding extra wait commands.

If you’ve tried using Selenium IDE to record and play a test, this is what happens in the same scenario where you try to click something that isn’t initially in the DOM:

Also note that the Selenium recorder picks very bad locators for an Ext JS application. Siesta would instead pick a Component Query to activate the tab: >>tab[text=Loadmasks].

Clicking a button in an expanding panel

If you use Ext JS panels, you have definitely seen that they are collapsible by default using animations. This also impacts our testing if you intend to interact with UI elements inside the expanding panel. After clicking the expand icon, we should wait until the panel is done animating itself to its new size. See the below illustration for an explanation of the issue:

This is now completely handled by Siesta, since detects the target moving and retries after a short delay.

Stress test – clicking a button that appears and disappears

To illustrate just how stable Siesta targeting is now, we also built a few stress tests. The first one has a rotating UI which spins two times then stops. No normal application would ever look like this, hopefully :). The second stress test has a button that is moved to random positions in the DOM for a while and then stops. Siesta will handle both of these crazy scenarios just fine now. To see for yourself how it looks, we made a simple demo video that you can view below.

[youtube id=”BNANTir7YfY” width=”550″ height=”300″]

Conclusion

We think this latest improvement will help you a lot in your application testing to ensure tests are as robust as possible. If you have additional ideas or feedback about tricky testing use cases, please let us know and we’ll try to see how you can make Siesta better.