A Playwright locator for issue cards matches three more elements than the board renders. How do you narrow it with locator.filter?

## Diagnose before you filter A count that is off by three is information, not noise. Before changing the locator, find out **what the extra matches are**. The cheapest way is to read the whole set back: ```ts const cards = page.getByTestId('issue-card'); console.log(await cards.count()); console.log(await cards.allTextContents()); ``` `allTextContents()` reads raw `textContent` for every match, including elements that are not rendered — which is exactly what you want here, because invisible extras are the usual culprit. Contrast it with `allInnerTexts()`, which reports rendered text only: if a card shows up in the first list and as an empty string in the second, you have just proved it is hidden. That two-line diff is faster than any amount of staring at the DOM. The extras almost always turn out to be one of: - a **hidden card template** the framework keeps in the DOM for cloning; - cards from a **collapsed or off-screen column** that share the same test id; - **stale nodes** from the previous board still in a leaving transition; - an **ancestor** that also matched, because the starting locator was too loose. ## Narrowing by visibility For the first three, `locator.filter({ visible: true })` — available since Playwright 1.51 — keeps only the elements that are actually visible: ```ts const visibleCards = page.getByTestId('issue-card').filter({ visible: true }); await expect(visibleCards).toHaveCount(6); ``` Passing `visible: false` inverts it and matches only the invisible ones, which is occasionally useful for asserting that a template stayed hidden. Playwright 1.63 also adds a `locator.visible()` shortcut for the common `visible: true` case; the filter option is the general form and reads naturally alongside other filter conditions. ## Narrowing by content For extras that are visible but simply not the cards you meant, exclude them by what they contain: - `filter({ hasNotText: 'Archived' })` drops cards mentioning that word anywhere in their subtree, case-insensitively; - `filter({ hasNot: page.getByTestId('placeholder-badge') })` drops cards containing a matching descendant, with the inner locator resolved relative to each card. Both keep the match on the card, so whatever you do next still targets the container. ## Which exclusion fits | The extras are | Reach for | |---|---| | present but not rendered | `filter({ visible: true })` | | rendered, identified by wording | `filter({ hasNotText: '…' })` | | rendered, identified by a child | `filter({ hasNot: someLocator })` | | ancestors of a real card | a tighter starting locator | | in another container entirely | scope with `column.locator(cards)` | That last row matters: if the extras live in a different column, the honest fix is scoping the search to the container you mean, not filtering the whole page's worth of results afterwards. ## What not to reach for Three tempting shortcuts each hide the problem instead of fixing it: 1. **Indexing past the extras.** Taking a fixed position works until the hidden nodes render in a different order, and it encodes a DOM detail nothing guarantees. 2. **Forcing the action.** Skipping actionability checks does not make the locator correct; it makes a wrong-element click succeed silently. 3. **Waiting longer.** A hidden template does not disappear with time. If the count is wrong because of extra nodes rather than timing, no timeout value fixes it. ## Keeping the fix honest After narrowing, lock the result in with a retrying count assertion so a regression that reintroduces the extras fails loudly rather than being absorbed. And prefer the narrowest fix that names the real distinction: `visible: true` when visibility genuinely is the difference, a content exclusion when it is not. A filter chosen because it happens to produce the right number today is a locator that will mislead the next person who reads it.