Selectors for multi-step browser tests
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 right elements and robust enough to withstand 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 describes some common selectors 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 of these identifiers are more static than others. Page elements can change with site redesigns, and even between user sessions. For example, if a page is rendered with React, you'll often see attribute values with random strings that change with each page refresh. This means you'll need to be intentional with the selectors you pick.
- 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 some uniqueness 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 intentionally 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 (CTA). 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="homepage-sidekick_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="homepage-sidekick_header_CTA-text"]
- If your HTML element looks something like
- 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.
- 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, for example,
//button[@aria-label='Sign in']
- The format is generally
- 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: