Quality assurance of modern web applications is more important than ever. Today’s end users are demanding and do not tolerate login problems or flawed checkout processes – instead they switch to the competitor’s platform. Continuous deployment and ever shorter release cycles require us to automate our quality assurance more and more – bringing “automated web testing” to the table.
The first release of the W3 specification for the WebDriver API in 2012 and its implementation by all major browsers have made automated web testing possible for the masses. New Web 2.0 companies like SauceLabs allow you to run web tests in a range of controlled environments ensuring that your web applications run everywhere with the same pleasant level of user experience.
Modern web applications, featuring lots of dynamic DOM changes, however, have made the web tester’s life more difficult. We identified three core reasons:

  1. Stability of tests in dynamic scenarios
  2. Robustness of large test suites against frequently changing user interfaces
  3. Run time of test suites

Tackling each of them has enabled us to raise our quality bar while simultaneously shipping faster.

Stability of Tests in Dynamic Scenarios

Fortunately, the WebDriver API ensures that all JavaScript onload handlers have been executed before the next test step is executed. However, modern applications make extensive use of dynamic DOM changes and setTimeout() calls. Determining when page loading is “really finished” is often hard and web test developers are inclined to introduce waiting timeouts (the dreaded thread sleep calls) into web tests to overcome race conditions.
We recommend extensive usage of WebDriverWait instead, optimally combined with a hidden indicator flag on the page. Web test developers can rely on WebDriverWait-ing for this flag after each step and do not have to invest too much time into finding good WebDriveWait conditions.

Robustness of large Test Suites against frequently changing User Interfaces

User interfaces are no longer driven by computer programmers. Designers and user interface experts have been hired to take over and they frequently improve (in other words “change”) HTML structures to better reflect customer needs. Large web test suites must prepare for such changes from the very beginning. Changing hundreds of tests only due to a change of the login screen is not feasible for any company.
We recommend using the well-known PageObject pattern to adapt to changes on a single page. A “UserTask” pattern can be used to abstract recurring tasks (e.g., “Login”, “Create new item”, …) which may then be combined in web tests to build a complete (and also much more readable) test.

Run time of Test Suites

Extensive usage of sleep calls to prevent race conditions and preparing test data via WebDriver calls are equivalent to driving with the handbrake on. Web tests should prepare test data via a more direct way (e.g. by preparing the database) instead of creating test data during test execution. This has the additional advantage that the test code concentrates on the actual feature under test.
Following these guidelines enabled us to write automated web test suites for large web applications even in the new Web 2.0 world. Do you have your own thoughts on the topic? Experiences? Recommendations? What worked well for you? What didn’t? Visit our round table at the We Are Developers 2016 conference!

LEAVE A REPLY

Please enter your comment!
Please enter your name here

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

If you agree to these terms, please click here.