@elastic/eui-test-helpers 1.4.0 → 1.5.0

package/src/components/filter_button/README.md

@@ -0,0 +1,29 @@
+# EuiFilterButtonObject
+
+Playwright Component Object for [EuiFilterButton](https://eui.elastic.co/docs/components/forms/filter-group/).
+
+## Usage
+
+```ts
+import { EuiFilterButtonObject } from '@elastic/eui-test-helpers';
+
+const filterButton = new EuiFilterButtonObject(page, 'myFilterButton');
+await expect(filterButton.locator).toHaveClass(/euiFilterButton-hasActiveFilters/);
+await expect(filterButton.notificationBadge).toHaveText('2');
+```
+
+Set `data-test-subj` on the `<EuiFilterButton>` (EUI spreads it onto the button itself, which the component-type guard verifies).
+
+## API
+
+| Member | Description |
+|---|---|
+| `locator` | Inherited root `Locator`. Assert the button's active/selected state directly on it, e.g. `toHaveClass(/euiFilterButton-hasActiveFilters/)` or `toHaveClass(/euiFilterButton-isSelected/)` — both are synchronous CSS classes EUI sets, not async state. |
+| `notificationBadge` | `Locator` for the filter-count badge. Only present when the consumer passes `numFilters` or `numActiveFilters`. |
+
+## Deliberately out of scope
+
+This component does not own opening or closing a popover the button triggers, or reading/selecting options inside it:
+
+- **Popover mechanics**: `EuiPopover` already sets `aria-expanded`/`aria-controls` on its toggle button synchronously itself. Drive open/close from your test directly against those, or the popover's own `isOpen` prop in your app.
+- **Option selection**: when the popover content is an `EuiSelectable`, scope [`EuiSelectableObject`](../selectable/README.md) to it instead of reimplementing option matching here.

package/src/components/form/range/README.md

@@ -0,0 +1,31 @@
+# EuiRangeObject
+
+Playwright Component Object for [EuiRange](https://eui.elastic.co/docs/components/forms/range-controls/) and `EuiDualRange`.
+
+## Usage
+
+```ts
+import { EuiRangeObject } from '@elastic/eui-test-helpers';
+
+const range = new EuiRangeObject(page, 'myRange');
+await range.slider.fill('50'); // or press arrow keys, drag, etc.
+```
+
+Set `data-test-subj` on the `<EuiRange>`/`<EuiDualRange>` (EUI spreads it onto the native range slider, which the component-type guard verifies).
+
+## Why this exists
+
+On a plain `EuiRange` rendered with `showInput`, EUI spreads the *same* `data-test-subj` onto both the native slider and the visible number input. A plain `page.getByTestId(x)` then resolves to two elements and throws in Playwright's strict mode. That is a real, non-obvious EUI gap this component exists to hide.
+
+## API
+
+| Member | Description |
+|---|---|
+| `slider` | `Locator` for the native `<input type="range">`. Resolves to exactly one element once mounted. With `showInput="inputWithPopover"`, the slider lives inside the popover panel and is not mounted until the popover opens (focus/click `numberInput` to open it). |
+| `numberInput` | `Locator` for the visible number input. Only present on a plain `EuiRange` with `showInput` set, resolves to zero elements otherwise. |
+
+## Deliberately out of scope
+
+- **`EuiDualRange`'s min/max number inputs**: rendered only with `showInput`, and need their own `data-test-subj` via `minInputProps`/`maxInputProps`. That is the consumer's own test-subj to target directly, not ambiguous the way the plain `EuiRange` case is.
+- **`inputWithPopover` open/close** (`EuiRange` and `EuiDualRange` both support this mode): the popover only opens by clicking a number input, not the delimiter between them. That is a real EUI behavioral quirk, but a single documented fact rather than DOM ambiguity, and popover mechanics are already exposed synchronously by `EuiPopover` itself (`aria-expanded`/`aria-controls`). Drive it from your test directly.
+- **Reading the current value**: use `slider.inputValue()` or `numberInput.inputValue()` directly, no wrapper needed.