🚨 Common Errors

Common Errors: Most locator errors arise from not knowing the source-DOM-render distinction and always settle into the same few patterns: locating before the element renders (NoS

Most locator errors arise from not knowing the source-DOM-render distinction and always settle into the same few patterns: locating before the element renders (NoSuchElement), using a reference that died after a re-render (StaleElement), binding to a hash class, searching without a wait for an element NOT in the DOM due to `*ngIf`/conditional, forgetting the iframe/shadow DOM context. Why an "error dictionary"? Because a tester who recognizes the root cause the moment they see the error message solves it in minutes; one who cannot tries blindly for hours. Java analogy: like thinking "which reference is null?" when you see a NullPointerException — the message tells you the path to the root cause. In QA context: this group presents each error in a Symptom -> Root Cause -> Fix -> Prevention format; every error bridges back to a GROUP you already saw on this page.

🎬 Stale Element: How a Reference Dies

A test finds the "Edit" button and stores it in a VARIABLE: `const editBtn = await driver.findElement(...)`. In this film you will watch HOW this reference SILENTLY dies once a new bug is added to the list.

Step 1 — the element is found and a reference is HELD: `editBtn` now points to a SPECIFIC node in the DOM (the "Edit" button as it currently exists).

Step 2 — a different action (e.g. clicking "Load More") triggers a RE-RENDER: because the list state changed, React/Angular decides to RECREATE this subtree (recall the reconciliation lesson from GROUP F1/G1).

Step 3 — the old node is DESTROYED, a NEW node is built: even though the framework visually draws the same button in the SAME place, underneath it may have created a BRAND NEW DOM node — the old node no longer EXISTS in the document.

Step 4 — the held reference now points to a GHOST: `editBtn` still points to the OLD node, but that node is no longer ATTACHED to the document — a "stale" reference.

Final — calling `editBtn.click()` throws `StaleElementReferenceException: element is not attached to the page document`. The right reflex: instead of holding a reference beforehand and using it LATER, RE-QUERY the locator before EVERY interaction (Playwright locators do this automatically, Selenium requires calling `findElement` again by hand).

Step by Step: Where Does the Error Message Point You?

No error at all, but the result is wrong

The test is "green" but processed the wrong bug — suspect: did an index-bound locator silently fall onto the wrong element once ordering changed (GROUP H2/H5)?

"0 elements matched" / NoSuchElement

The element was not found at all — has it not entered the DOM yet (timing, GROUP D3), was the condition not triggered (GROUP F4/G3), or is the selector written incorrectly?

"not attached to the page document" / StaleElement