core: fix BadgeElement text scope and move theme-variant asserts to mixin (#165)

[jcgueriaud1]

Fixes #165 — the four code findings from the review of #156.

1. assertText() / getText() no longer pick up slotted icon text

BadgeElement asserted on the host's full textContent, but the Javadoc promised "only the badge's own text content". Any icon that renders a glyph in the light DOM broke that: new Badge("Verified", new Span("✓")) gives the host textContent == "Verified✓", so assertText("Verified") timed out and getText() returned "Verified✓".

getText() is now an override that evaluates over childNodes and keeps only nodes with no slot attribute — the > :not([slot]) convention CardElement.getContentLocator() already uses. assertText() compares against that.

2. getByText() Javadoc corrected

The Javadoc claimed the shadow-rendered number is excluded from the match, but Playwright's hasText filter uses the same shadow-traversing elementText as toHaveText, so getByText(page, "5") matches a badge whose only "5" is its number.

A light-DOM-only filter isn't expressible as a Playwright locator, so I took the other option the issue offers: the Javadoc now states the number is part of the matched text, with the concrete example, and advises passing some of the badge's own text.

3. Theme-variant helpers moved to HasThemeElement

Nothing in assertHasThemeVariant / assertHasNoThemeVariant / themeVariantPattern was Badge-specific — they work for any space-separated Vaadin theme attribute, and the 27 elements implementing HasThemeElement combine variants the same way. They are now default (and private static) members of the mixin.

The new ButtonViewIT.testHasThemeVariant shows why this mattered: addThemeVariants(LUMO_PRIMARY, LUMO_SMALL) renders as theme="small primary", so a whole-attribute assertTheme is order-sensitive in a way that isn't the order the variants were added.

4. assertNumber() reports expected/actual

assertNumber(9) against a badge showing 8 reported only TimeoutError: Timeout 30000ms exceeded while waiting for condition. The non-null case now uses assertThat(getLocator()).hasJSProperty("number", number) for Playwright's standard expected/received message; the null case asserts absence of has-number.

I confirmed the review's has-number claim against the 25.3.0-beta1 @vaadin/badge source before relying on it — willUpdate does this.toggleAttribute('has-number', this.number != null), i.e. exactly when number != null.

assertText() has to stay on waitForCondition (its value is computed, not a JS property), so its timeout is now wrapped in an AssertionError naming both the expected and the actual text.

5. GEMINI.md

Left to #147 as the issue directs.

Test coverage

New ITs:

• BadgeViewIT.testTextExcludesIconSlotText — a Span("✓") icon, host textContent "Verified✓", own text "Verified" (fails on master)
• BadgeViewIT.testGetByTextMatchesShadowNumber — getByText(page, "5") resolves to the numbered badge, not the one reading "5 minutes", pinning the newly documented behaviour
• BadgeViewIT.testNumberMismatchReportsExpectedAndActual / testTextMismatchReportsExpectedAndActual — the failure message names both values
• ButtonViewIT.testHasThemeVariant — the mixin off Badge

New test-UI fixtures: #badge-with-text-icon, #badge-minutes, and a combined-variants button.

Full suite: 671 tests, 0 failures (./mvnw -Pit verify). api-reference.md regenerated.

🤖 Generated with Claude Code