Skip to main content
Lantern Home
 
 
Splunk Lantern

Selectors for multi-step browser tests

  1. Last updated
  2. Save as PDF

 

In CSS, selectors are patterns of elements and other terms that tell the browser which HTML elements should be selected to have the CSS property values inside a rule applied to them. When creating a browser test, it's important to choose selectors to test that are both specific enough to target the correct elements and robust enough to survive minor release changes. You aren't sure which ones you should use.

You can find all elements matching your selector by using the console. Learn more about using the console with the Console Utilities API reference and Learn HTML.

Solution

This article provides selector examples that you can add when creating the test from scratch in the Splunk Synthetic Monitoring GUI.

Splunk Synthetic Monitoring supports the import of JSON via API or through the GUI for Browser Tests. Use the built-in Chrome Recorder to create a test in an incognito browser window, re-run the test to validate it, and import into Splunk Synthetic Monitoring. Keep in mind that better selectors might be needed beyond what the recorder captures. See a demo here.

Inspecting the DOM to identify elements

In Chrome, on your webpage, right-click the object you're interested in and click Inspect. This opens the dev tools so you can see the markup.

Reading and choosing element selectors

  • As you read the markup you can begin to see the patterns to look for. In general, the pattern in HTML is: <element attribute="attributeValue">;content</element>
  • Some element identifiers are more reliable than others. Page elements can change with site redesigns, and even between user sessions. For example, if a page is rendered with React, you often see attribute values contain random strings that change with each page refresh. This means you need to be intentional with the selectors you pick so your tests are easier to maintain.
  • Avoid using vague elements like <div>.
  • Keep in mind that styles, architecture, and text can change between site releases, which will break your tests. For example, if you right-click an object and copy a selector that looks like /html/body/div/div[2]/div[3]/div/div/button[2], this is brittle and will break with any change to the page structure. Instead inspect the element, find something unique about it, and write an intentional selector using the syntax below.
  • Aria labels, ids, and data attributes are great to use, as they are designed to be unique and specific. It will take some practice inspecting the DOM and testing selectors within the Splunk Synthetic Monitoring GUI.
  • Remember that multiple elements can have the same attributes (for example, CSS class) so the test picks only the first element it encounters on the page that fulfills that criterion. You can find all elements matching your selector by using the console.

Selector examples

You can target the element, its attribute, and the value of that attribute, and sometimes the content within the element itself. You do this via css, xpath, id, JS path, and even javascript. When in doubt, use Google to find more help.

  • The id attribute should have no duplicate values per web page, in which case it's an ideal unique selector. Unfortunately that is not always the case, and not all elements require an id attribute. If your element has this attribute, and the value is static, this is a great choice.
  • Use a css selector where the element has a reliable, unique identifier, for example, a sign in button or major call to action. The format is element[attribute="attributeValue"]. For more information on this syntax, refer to the Mozilla docs about css attribute selectors. Examples: 
    • If your HTML element looks something like <button aria-label="Sign in" class="buttonPrimary">Access my account</button> the class could apply to any number of buttons on the page, and the button text could change at any time or with any A/B testing on that element. button[aria-label="Sign in"] is the most likely selector to reliably identify this element in your synthetic test if you know that this element will most likely remain a button and that the aria-label will remain static and unique.
    • If your HTML element looks something like <a href="https://www.mysite.com/CTA2023" data-testid="header_CTA-text">Get this deal!</a> that's great, because the data-testid is a reliable and unique attribute. A good selector for your Synthetics test could be: a[data-testid="header_CTA-text"]
  • The following examples use an xpath selector where the element has an attribute containing both static and dynamic values. Xpath can also be used similarly to css above, where the values are static. Learn more about XPath.
    • The format is generally //element[rule(attribute,'attributeValue')]
      Looks for the input element with an id starting with the string 'checkInDate'
    • //input[starts-with(@id,'testInDate')]
      • For example, sometimes the attribute values will be appended with a character string that changes for each user session. So using "starts with" ensures that you target that element regardless of if it becomes testInDate-3489, testInDate-2467, etc.
    • //*[text()[contains(.,'Registration')]]
      Looks for any element containing the text string 'Registration'
      • This one is often too vague but can work on some sites.
      • This is case-sensitive.
    • xpath can also be used with static elements, targeting one or more attributes:  In this example there could be multiple buttons on the same page, but only one with both of these attribute values: //button[@aria-label='Sign in' and @data-link='alpha']
  • Use javascript where the element attribute contains a reliable string for a critical function, such as login or testout, or where using another type of selector is unreliable.
    • document.querySelector('a[href*="account/login?testout"]').click();
      Looks for the anchor element with an href containing the string 'account/login?checkout'
  • Use conditional javascript where the element should be clicked if it appears, for example, with popups, which might be inconsistent.
    • if(document.querySelector('button[data-click="close"]')){document.querySelector('button[data-click="close"]').click();}
    • if(document.querySelector('[id^="close-button"]')){document.querySelector('[id^="close-button"]').click();}
      • Where the attribute value is expected to always contain "close-button" but might have some other string appended/ prepended

Next steps

You might be interested in these additional processes related to running Splunk Synthetic Monitoring browser tests:

Splunk OnDemand Services: Use these credit-based services for direct access to Splunk technical consultants with a variety of technical services from a pre-defined catalog. Most customers have OnDemand Services per their license support plan. Engage the ODS team at OnDemand-Inquires@splunk.com if you require assistance.

​