Web Automation

A modern framework's set of pre-action checks ensuring an element is truly ready before interacting — visible, stable (not animating), enabled, not covered by another element, and able to receive events. Cypress and Playwright run these automatically before a click/type, retrying until they pass or time out. It's the mechanism behind reliable auto-waiting.

A UI pattern that suggests completions as the user types, typically backed by a search or lookup endpoint. Testing concerns include: suggestions appearing for partial input, debouncing (requests should not fire on every keystroke), keyboard navigation through suggestions, screen-reader accessibility, and what happens when the backend is slow or returns no results. Also verify that selecting a suggestion correctly populates the target field and that the suggestion list closes on blur or Escape.

An isolated browser session with its own cookies, storage, and cache — like a fresh incognito window, but programmatic. Playwright's `browser.newContext()` creates one; each is fully independent. Contexts let one test run exercise multiple users simultaneously (e.g. a chat between user A and user B) without cross-contamination.

Charts, graphs, maps, and dashboards that render data graphically. Testing concerns span correctness (does the chart reflect the underlying data accurately, including edge cases like empty datasets, single data points, and very large values?), accessibility (colour-blind-safe palettes, ARIA labels on SVG elements, keyboard navigation), and rendering consistency across screen sizes and browsers. Snapshot or pixel-diff testing can catch visual regressions in chart rendering.

The Document Object Model — a tree-shaped, in-memory representation of an HTML (or XML) document that the browser builds after parsing the page source. Each element becomes a node, and JavaScript (and test tools like Playwright and Selenium) interact with the page by traversing and manipulating this tree. Understanding the DOM is essential for writing stable locators: a query like `#submit-btn` targets the DOM node, not the raw HTML string.

Telling a test to wait for a specific condition before proceeding — an element to be visible, a request to complete, text to appear — rather than pausing a fixed number of seconds (an implicit/hard wait). Explicit waits are condition-based and resolve as soon as the condition is met; hard sleeps waste time and still flake.

An HTML element embedding one document inside another — a separate browsing context with its own DOM. Payment forms, embedded maps, and third-party widgets commonly live in iframes. Their content is isolated: the parent page's selectors don't reach into an iframe without explicitly switching context.

An encapsulated DOM subtree attached to an element, whose internals are hidden from the main document's normal selectors — the technology behind web components. A `<custom-widget>` may contain a whole UI inside its shadow root that `document.querySelector` can't reach without explicitly crossing the boundary.

A dedicated HTML attribute (`data-testid`, `data-cy`, `data-test`) added solely so tests can locate an element reliably — decoupled from styling, copy, and structure. Because it exists only for testing, it doesn't change when designers restyle or copywriters reword, making it the most stable locator strategy.

A self-contained, reusable UI component — date picker, rich-text editor, file uploader, chart, or similar — embedded in a page or third-party surface. Testing a widget involves verifying its own behaviour (correct state transitions, keyboard accessibility, error states), its integration with the host form or page (does it emit the right value on change?), and edge cases specific to its type (date picker: leap years, min/max constraints; file uploader: MIME type and size limits). Third-party embedded widgets also require cross-origin and content-security-policy testing.