UNTestable: It's Just Pressing a Button, How Hard Could it Be?

Over the last 7 years, I've consulted several testing teams on test automation projects for their web applications, and the most frequent troubleshooting request I get is about clicking some button on some website.

It's just pressing a button... how hard could it be... right?

I came to discover there's many edge cases when it comes to simply executing a click on a button.

For example, how do you click a button that re-renders when the mouse hover over it? If you tried to click on the button that used to be there before, then you'll get a "stale element reference".

How about a button that moves when the mouse goes over it?

How about a button that is partially obscured by another element?

How about a button nested in several scrollable containers?

Unfortunately, these trick buttons are real scenarios I've seen in real business applications.

In this presentation / live coding session, I'll show you some trick buttons, and how to hit them on the bullseye.


Outline/Structure of the Deep Dive Session

  • Self introduction
  • Live coding to solve different trick buttons with Selenium/Webdriver:
    • Trick button 1: "The clone" - Button that re-renders when mouse hover over it
    • Trick button 2: "The dodgeball" - Button that moves when mouse hover over it
    • Trick button 3: "The glass door" - Button that is partially obscured by another element (an unfortunately common issue)
    • Trick button 4: "The russian doll" - Button nested in several scrolling container

Learning Outcome

Learn how to automate clicking on elements for tricky but not uncommon edge cases.

I thought about creating a subversive series on UNtestable UI elements, and this is a lesson on how to make UNtestable buttons.

Target Audience

Experienced test engineers

Prerequisites for Attendees

This session includes some live coding using Selenium / Webdriver and assumes that the audience is already familiar with Selenium / Webdriver syntax.

schedule Submitted 1 month ago

  • Liza Ivanova

    Liza Ivanova - Declarative UTAM Page Objects

    40 Mins
    Deep Dive Session

    Page Objects design pattern is commonly used by most automation developers because it provides encapsulation and ensures maintainability of UI tests. The larger and more complex is application, the more UI tests teams have to write and maintain, and the more important it is to maintain 1:1 relations between UI component and a Page Object. But design pattern on its own does not ensure good quality of the page object code, that's why we created UTAM.

    UTAM provides declarative JSON based language to create page objects and compilers to transform declarative code to Java, JavaScript or TypeScript. Generated code is based on Selenium library (for Java) or WebdriverIO (for Javascript), but UTAM allows to build custom integration layer to use any framework for UI interactions. Generated code is high quality and uses all best practices like explicit waits and CSS selectors only (XPATH not supported). It's very easy to write UTAM JSON and even easier to generate it automatically from any HTML source.

    UTAM declarative language has support for mobile automation as well (both IOS and Android) and Shadow DOM.

    We provide extensive documentation and online interactive tutorials on UTAM web portal https://utam.dev/tutorial/introduction for better learning experience. We also created browser extension to partially generate UI tests https://chrome.google.com/webstore/detail/utam/llgodnekeleaidcljgfljjechnjdgnli 

    Our goal with UTAM is to increase maintainability of the page objects and development productivity to produce overall better experience.

  • David Burns

    David Burns - Why Browser Engines ≠ Real Desktop Browsers ≠ Mobile Browsers

    40 Mins

    All of us have tested on either headless browsers, browser engines or responsive mode for mobile. However, there are a lot of differences between an actual browser, desktop and mobile, vs a simulated one.

    In this talk I’ll walk you through real world examples that show you the gaps you can miss while testing:

    1. In headless mode

    2. Browser engines

    3. Responsive mode for mobile browsers

    I’ll also share the technicalities of why this happens and my learnings from having worked on a browser engine.

  • Boni García

    Boni García - Selenium Manager: Automated Driver & Browser Management for Selenium WebDriver

    Boni García
    Boni García
    Staff Software Engineer
    Sauce Labs
    schedule 1 month ago
    Sold Out!
    40 Mins

    Selenium WebDriver is an open source library that allows controlling web browsers (e.g., Chrome, Firefox, Edge, etc.) programmatically using different languages (such as Java, JavaScript, Python, Ruby, or C#). Internally, Selenium WebDriver uses the native support implemented by each browser to carry out the automation process. For this reason, we need to place a component called driver (e.g., chromedriver, geckodriver, msedgedriver, etc.) between the script using the Selenium WebDriver API and the browser. 

    Historically, the Selenium project did not cover the automated management (understood as the process of download, setup, and maintenance) of drivers. For this reason, different projects in the Selenium ecosystem emerged to do this task (such as WebDriverManager in Java or webdriver-manager in Python, among others). As of Selenium 4.6.0, automated driver management is shipped in Selenium WebDriver out of the box. This way, the driver management is done automatically and transparently for all Selenium WebDriver binding languages. This process is done through a new official tool of the Selenium portfolio called Selenium Manager.

    Selenium Manager is a CLI tool developed in Rust. It provides a robust mechanism to detect the version of the local browser to be controlled with Selenium WebDriver, download the proper driver, and make it available for Selenium WebDriver. Moreover, Selenium Manager has another relevant feature in its roadmap: the automatic management (i.e., download and installation) of browsers (such as Chrome, Firefox, or Edge).

    Selenium Manager has been built with the lessons learned from the development of WebDriverManager (first released in 2015). This way, the history of Selenium Manager is the history of how an independent third-party project has become part of the Selenium code development.