bermudalamb
549a08038e
favorites, favorites-filter, sold-filter, orders and pending-publish. Five more copies of "register a customer" and three more of the hardcoded base URL go with them. Two locators that were hiding real knowledge are now named. `gridCell` is the item's whole antd column rather than its card, needed because the SOLD ribbon renders outside the card — three specs reached for `.ant-col` directly to get at it. And `chooseAvailability` goes through the title attribute because antd's Segmented hides the real radio behind a styled label, so the input is found by role and cannot be clicked; that fact was written out twice in comments and is now written once in code. The favorite control is located page-wide rather than within a card. The storefront paginates as items accumulate and the control is named for its item anyway, so scoping to a card bought nothing and broke whenever the card was on another page. favorites-filter keeps its local `favorite()` helper. It is genuinely local — decline the opt-in, wait for the fading modal to stop intercepting pointer events, confirm the heart flipped — and belongs to that file's subject rather than to the storefront. It now takes page objects as parameters instead of reaching for locators itself, which is what a spec-level helper should look like. Two specs still drive the registration form rather than taking the `customer` fixture, and deliberately. Both are about a signed-out visitor being interrupted mid-action — favoriting an item, or switching on the favorites filter — and the claim is that the thing they asked for survives the interruption. Replacing the interruption with an API call would delete the test. Verified: favorites 6/6, favorites-filter 7/7, sold-filter 6/6, orders and pending-publish 8/8. Notably favorites-filter's "keeps showing a favorite after it sells" passes, which had been failing on a strict-mode violation from two items sharing a name across runs. Refs #137
35 lines
1.2 KiB
TypeScript
35 lines
1.2 KiB
TypeScript
import { Locator, Page } from '@playwright/test';
|
|
|
|
/**
|
|
* The modal offered when a customer favorites an item: an opt-in to hear if it
|
|
* sells, with the reason for asking.
|
|
*
|
|
* `getByRole('dialog')` unqualified is deliberate and safe — the storefront
|
|
* shows one modal at a time, and a signed-out visitor clicking the heart gets
|
|
* the auth prompt instead, which is a different object.
|
|
*
|
|
* The opt-in is deliberately not the marketing consent. Accepting item alerts
|
|
* must not sign anyone up for marketing, which is why the tests read both flags
|
|
* back off the API rather than trusting the copy.
|
|
*/
|
|
export class FavoritePrompt {
|
|
readonly dialog: Locator;
|
|
readonly acceptAlertsButton: Locator;
|
|
readonly declineAlertsButton: Locator;
|
|
|
|
constructor(page: Page) {
|
|
this.dialog = page.getByRole('dialog');
|
|
this.acceptAlertsButton = this.dialog.getByRole('button', { name: 'Yes, email me' });
|
|
this.declineAlertsButton = this.dialog.getByRole('button', { name: 'No thanks' });
|
|
}
|
|
|
|
async acceptAlerts(): Promise<void> {
|
|
await this.acceptAlertsButton.click();
|
|
}
|
|
|
|
/** Declining keeps the favorite; only the alerts are refused. */
|
|
async declineAlerts(): Promise<void> {
|
|
await this.declineAlertsButton.click();
|
|
}
|
|
}
|