A test that passes locally and fails in CI because a button changed its ID by one character is not a Selenium problem. It is a locator and synchronization problem. If you are learning how to handle dynamic elements in Selenium, the goal is not to chase changing attributes faster. The goal is to build tests that identify elements the way a user experiences the page and wait for the UI to reach a usable state.
Dynamic elements show up in almost every modern web app. React, Angular, Vue, server-side rendering, virtualized lists, delayed API calls, and client-side re-renders all create moving targets. An element may exist in the DOM but not be visible yet. Its ID may be generated at runtime. Its text may update after an API response. A button you stored earlier may become stale after the page re-renders.
That is why brittle Selenium tests tend to cluster around the same symptoms: NoSuchElementException, StaleElementReferenceException, ElementClickInterceptedException, and timeouts that seem random. The fix is rarely one trick. It is a combination of better locators, explicit waits, and test design that expects the DOM to change.
How to handle dynamic elements in Selenium without brittle tests
The first decision is always locator strategy. If your test depends on an autogenerated ID like input_45291 or a CSS class from a styling framework that changes across builds, the test is already fragile. Prefer attributes that express business meaning and remain stable across releases, such as data-testid, data-qa, name, aria-label, or a predictable text label near the control.
A good locator should survive visual redesigns and minor DOM restructuring. For example, locating a search field by a dedicated test attribute is far stronger than finding the third input inside a random container. Index-based XPath can work in a pinch, but it usually breaks when the layout changes.
Here is a simple Java example using a stable attribute:
“`java By searchInput = By.cssSelector(“[data-testid=’search-input’]”); wait.until(ExpectedConditions.visibilityOfElementLocated(searchInput)).sendKeys(“Selenium”); “`
If the app does not provide stable test attributes, use relationships in the DOM instead of volatile IDs. You can anchor to nearby text, labels, or section containers that are less likely to change.
“`java By emailField = By.xpath(“//label[normalize-space()=’Email’]/following::input[1]”); “`
This is still not as strong as a purpose-built test attribute, but it is usually better than chasing generated values.
Use explicit waits for state, not just presence
Many engineers know they need waits but still apply them too broadly or in the wrong place. Presence is not enough for most interactions. A dynamic element can be present in the DOM and still be hidden, disabled, covered by an overlay, or about to be replaced.
Use explicit waits that match the action you want to perform. Wait for visibility before typing. Wait for clickability before clicking. Wait for text to update when asserting a status message. Wait for invisibility when a loader must disappear before the next step.
“`java WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10)); By saveButton = By.cssSelector(“[data-testid=’save’]”); wait.until(ExpectedConditions.elementToBeClickable(saveButton)).click(); “`
This matters because dynamic UIs often transition through intermediate states. Clicking as soon as the element exists can still fail if an animation or spinner is blocking the interaction. On the other hand, long hard-coded sleeps slow the suite and still do not guarantee correctness. A two-second sleep is wasted time when the element is ready in 200 milliseconds and still too short when the backend is slow.
If you are testing heavily asynchronous pages, custom waits are often worth the effort. For example, you may need to wait until a table row count stabilizes or until a loading class is removed from a component.
“`java wait.until(driver -> driver.findElements(By.cssSelector(“.loading-spinner”)).isEmpty()); “`
The trade-off is readability. Custom wait logic should be wrapped in reusable helper methods so your test flow stays clear.
Expect stale elements after re-rendering
A common source of confusion is the stale element reference. Selenium found the element correctly, but the framework re-rendered that part of the page and the old reference is no longer valid. This is typical in modern frontend frameworks when a component refreshes after input, filtering, or save actions.
The safest pattern is simple: do not store WebElement references longer than necessary on pages that update frequently. Store the locator, then re-find the element right before the interaction.
This is more reliable:
“`java By filterInput = By.cssSelector(“[data-testid=’filter’]”); wait.until(ExpectedConditions.visibilityOfElementLocated(filterInput)).sendKeys(“Active”); “`
Than this:
“`java WebElement input = driver.findElement(By.cssSelector(“[data-testid=’filter’]”)); // page updates input.sendKeys(“Active”); “`
If stale references happen in a known transition, wait for the old state to disappear and then locate the element again. In a well-structured page object, this usually means your methods should use locators and waits internally rather than exposing raw WebElement instances across test steps.
Build smarter XPath and CSS selectors
When teams ask how to handle dynamic elements in Selenium, the real issue is often selector quality. Dynamic attributes do not mean XPath is required, and CSS is not always enough. Use the tool that expresses the most stable intent.
CSS selectors are fast and readable for stable attributes, classes, and hierarchy. XPath becomes useful when you need to match text, move relative to a label, or combine conditions that CSS cannot express cleanly.
For dynamic IDs with predictable fragments, partial matching can help:
“`java By dynamicButton = By.cssSelector(“button[id^=’submit_’]”); By dynamicRow = By.xpath(“//tr[contains(@id,’order-row’)]”); “`
Use this carefully. Partial matches are helpful only when the stable part is truly meaningful. If several elements share the same prefix, your selector may become ambiguous and cause intermittent failures.
Text-based XPath is also useful, but avoid depending on text that changes with localization, formatting, or business copy updates unless that text is itself what you are validating.
Handle collections that change size or order
Dynamic pages often render lists, grids, and search results that update after sorting, filtering, or lazy loading. In these cases, selecting the nth item is risky unless the position is part of the requirement.
A better approach is to locate the item by its visible business value and then find the action inside that row or card. If you need to click the Edit button for the user named Jordan Lee, locate the row containing that name and then scope the button search within that row.
“`java By userRow = By.xpath(“//tr[td[normalize-space()=’Jordan Lee’]]”); WebElement row = wait.until(ExpectedConditions.visibilityOfElementLocated(userRow)); row.findElement(By.cssSelector(“[data-testid=’edit-user’]”)).click(); “`
This pattern maps more closely to how users identify content and reduces failures when sorting or pagination changes.
For infinite scroll or lazy-loaded content, add logic that scrolls and waits for the next chunk to load. The exact approach depends on the application. Some pages append new elements, while others recycle DOM nodes for performance. In virtualized UIs, an item may not exist in the DOM until scrolled into view, so a basic presence check can be misleading.
When JavaScript helps, and when it hides a real issue
There are cases where standard Selenium actions struggle with dynamic elements. A sticky header may cover the target. The element may need to be scrolled into view. A custom component may react differently from native HTML controls. In those situations, JavaScript can be useful for scrolling or inspecting state.
What you should avoid is using JavaScript click as the default fix for every flaky interaction. It can bypass the same user-facing constraints your test is supposed to validate. If a real user cannot click because a modal overlay is blocking the button, forcing the click with JavaScript hides a legitimate issue.
Use JavaScript as a targeted tool, not a blanket workaround.
The maintainability layer matters most
Stable automation is not just about a single locator. It is about where you put that logic. Centralize selectors, waits, and dynamic-element handling inside page objects, component objects, or a similar abstraction. That gives you one place to update when the UI evolves.
It also helps to define team standards. Ask developers to add test-friendly attributes. Avoid writing tests against styling classes. Make explicit waits the default. Keep page methods focused on user actions and page state, not low-level Selenium calls scattered across the suite.
This is where structured training makes a difference. Teams that practice these patterns consistently produce tests that survive product change far better than teams that rely on ad hoc fixes.
Dynamic elements are not an edge case anymore. They are the normal shape of modern web applications. If you choose stable locators, wait for the right state, re-find elements after re-renders, and design your framework around maintainability, your Selenium suite becomes far less fragile and much more useful. The best test code does not fight the UI on every run – it understands how the UI changes and works with it.