What scenarios scare you the most about your test automation? Drag-and-drop? File uploads? Well, face your fears and test them against these great sites for verifying your automation’s performance. The web is a massive, heterogeneous beast and growing larger every year. So, don’t be discouraged if there are new web experiences that you aren’t able to automate so easily. This guide covers a few “gotchas” about creating automated tests, and then dives into some of our favorite sites for testing Reflect.
Before diving into the question of what we can test, let’s cover some best practices around test automation, and why some things are hard to automate on a demo website for testing.
Don’t validate on dynamic content.
This seems intuitive but it’s perhaps surprising how dynamic many pages are. For example, search results that aren’t explicitly sorted are dynamic. So, if you’re interacting with a search result item, make sure that you have sorted the list explicitly or ensure that the way you are locating the element is stable.
Another example of dynamic content is data related to time. The best example here is a “news”, or “latest updates” section in the application. This data can change quickly, so you’ll want to eliminate the non-determinism in some way before interacting with the data as part of your test.
Mind element visibility.
Page content and structure changes often. If you take a screenshot of your web application today and compare it to a screenshot of your web application from a year ago, it’s likely changed in at least some small ways and potentially in very large ways. Keep this in mind when interacting with content that is below-the-fold, or behind a hidden menu. Most test automation tools require the elements to be visible in order to interact with them. If the tool supports scroll-into-view, use this to be resilient to changes in an element’s (x, y) location over time.
Clean-up your account state, if necessary.
It’s quite common to create a test account with minimal permissions in order to verify all of the functionality of your application like a real user. If your tests create any account state when they run such as posts or records, the presence of these data objects might cause subsequent test runs to fail. Keep in mind whether your test is validating the “empty state” of an account. If your goal is not to test the empty state then make the test resilient to there being multiple items in a collection, for example.
Another common account state failure is the new account registration flow on websites. The act of registering often requires that the email address is unique (i.e., not seen before). This will cause all subsequent test executions to fail if they use the same email address. Reflect uses substitution rules to dynamically inject random or other text values into tests at runtime.
Don’t test on w3schools.com.
The w3schools.com site seems like a great candidate for testing automation. While it does have great information about nearly every web-based interaction and event, the presentation of the information is simply atrocious. The site is riddled with ads and loads new ads continuously throughout the session. Loading up the site in a fresh browser session, which you’ll want to do to simulate a new user to your site, takes nearly 5 seconds with a modern Internet connection, hardware and browser. Ordinarily, we’d say a really complex or “heavy” site is a great test for your framework. But w3schools has such horrible performance that it’s actually unrealistic when compared to most web applications you would test in the wild.
With the warnings out of the way, let’s get down to it! These public sites are useful for measuring the quality of your test automation software, and they cover different web use cases from the conceptual to functional.
This site is maintained by the Selenium Framework specifically for the purposes of testing out your automation tooling. It has a ton of realistic user experiences, including a hover-based site menu, so it’s a perfect place to start when using a new automation tool. Since it has a shopping cart just like a real e-commerce site, you can also test out user interactions that rely on modified state—in this case, adding items to the shopping cart. This site also allows you to test out explicit sort orders, which relates to the dynamic content mentioned above.
keydowninstead of the more common
jqueryui (web actions)
The jqueryui site has all of the most common web actions you’ll find in the wild today, including drag-and-drop, accordions, resizing and tooltips. Our personal favorite is drag-and-drop and we use it often to verify our drag-and-drop support remains high-fidelity. There’s a spirited debate around the Internet about jQuery’s future relevance, so we’ll refrain from getting involved and linking to any sources, but it’s safe to say that there are many existing websites still using jQuery. As such, it remains a solid test for your automation framework.
A second major reason to consider using the jueryui actions as examples is that all of their actions are within
iframeelements. This serves as an excellent robustness test of the automation framework as
iframepresents some unique challenges compared to top-level frame interactions. While the use of
iframeelements is not rampant in the wild, it’s common.
jkorpela.fi (file upload)
This is a great site for testing simple file uploads. File uploads are common throughout the web today, but are a special interaction when compared to clicks, hovers, etc. While this site uses the standard
input[type=file]element rather than the more common styled
inputelements in the wild, it allows you to verify metadata about the uploaded file to ensure correctness.
sortable.jslibrary is one of the most popular framework-agnostic libraries for drag-and-drop, and it’s even used by GitHub. It’s a nice test for any drag-and-drop automation because it uses the native HTML5 DnD APIs by default, which is something Selenium doesn’t support by default. This is a challenging use case to automate for many automation tools, but it’s worth adding to a test suite since it’s indicative of the type of drag-and-drop behaviors you’ll see on real websites.
This list covers just a few of the sites that we use most often in our development of Reflect. If you have a site that you think we should test on, please let us know! We aim to produce the highest fidelity and most repeatable web tests on the market. We support drag-and-drop, file uploads, and hovers natively. If you’re interested in tests that work the first time, get in touch with us at firstname.lastname@example.org.