Answer.

Background:

The emergence of modern single-page applications (SPAs) based on React, Angular, Vue has led to new problems in UI test automation: asynchronous data loading, complex dynamic UI elements, client-side routing. Classic approaches (e.g. by selectors or statically rendered DOM) have become unreliable for such applications.

Problems:

Tests often "fail" due to loading delays, animations, and asynchronous changes to elements.
Instability of selectors (dynamic ids, classes, changes in DOM structure).
Difficulty in maintaining tests after changes on the frontend side.

Solutions:

Using explicit waits for the appearance or change of elements:

from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, 20)
my_element = wait.until(EC.visibility_of_element_located((By.ID, 'dynamic_id')))

Working with more stable locators (data-testid, unique attributes).
Organizing the testing infrastructure: mocking API responses, using special test-helpers.
Including special hooks or stable test-ids in the frontend.

Key Features:

Focus on stable locators and explicit waits
Validation of UI state through API or service events
Layered automation: unit + integration + E2E

Trick Questions.

Can you rely only on XPATH or CSS locators in tests for SPA?

No. XPATH/CSS locators often break with any changes in the DOM. It is better to use stable data-* attributes or test-ids specifically embedded in the elements.

Does Selenium/WebDriverWait solve all async issues?

No. WebDriverWait helps to avoid fails due to delays, but does not guarantee correct loading and the state of complex UIs. Additional checks, API mocking, and handling of UI states are required.

Is it enough to only check for the presence of visible elements on the page to confirm the UI loaded correctly?

No. You can mistakenly take an "empty" load as successful if the element is displayed but does not contain expected data or state. You need to validate the content and values of fields.

Common Mistakes and Anti-Patterns

Using dynamic or unstable locators
Implicit waits (sleep instead of explicit waits)
Checking only the presence of an element without validating its value/content
Lack of API/service response mocking

Real-life Example

Negative Case

Automated tests run on a schedule, use XPath selectors and sleep delays. After the UI update, half of the tests fail due to the absence of elements or their displacement with new id/class.

Pros:

Quick creation of automated tests
Simple structure

Cons:

Instability (flaky tests)
Difficulty in maintaining each release

Positive Case

Data-testids are embedded in the UI, tests use explicit waits and special test hooks. All network responses are mocked, and tests validate not only presence but also content of elements.