Playwright керує справжніми браузерами (Chromium, Firefox, WebKit) і перевіряє застосунок так, як ним користується людина.
import { test, expect } from '@playwright/test';
test('користувач оформлює замовлення', async ({ page }) => {
await page.goto('/products/42');
await page.getByRole('button', { name: 'Додати в кошик' }).click();
await page.getByRole('link', { name: 'Кошик' }).click();
await expect(page.getByRole('heading', { name: 'Кошик' })).toBeVisible();
await expect(page.getByTestId('cart-total')).toHaveText('1 999,00 ₴');
});
Локатори описують, як знайти елемент, а не сам елемент: пошук повторюється щоразу, коли до локатора звертаються. Пріоритет той самий, що в Testing Library: getByRole, getByLabel, getByText, і лише потім getByTestId. CSS-селектори на кшталт .btn-primary > span ламаються від зміни верстки.
Автоочікування - головна причина стабільності. Перед click() Playwright сам чекає, доки елемент буде прикріплений до DOM, видимий, стабільний (без анімації), увімкнений і не перекритий іншим елементом. Перевірки expect(locator).toHaveText() повторюються, доки не пройдуть чи не мине тайм-аут.
Звідки беруться нестабільні (flaky) тести:
| Причина | Як виправити |
|---|---|
page.waitForTimeout(2000) |
чекати на стан: await expect(locator).toBeVisible() |
перевірка значення один раз: expect(await el.textContent()).toBe(...) |
перевірка, що повторюється: await expect(el).toHaveText(...) |
| тести залежать один від одного чи від спільних даних | кожен тест створює свої дані, ізольований стан входу |
| реальні сторонні сервіси (платежі, карти) | підміна через page.route() |
| анімації й час | вимкнути анімації, фіксувати час через page.clock |
Повтор входу в кожному тесті повільний - стан автентифікації зберігають один раз (storageState) і перевикористовують.
Діагностика: trace: 'on-first-retry' у конфігурації записує трасу (знімки DOM, мережу, консоль для кожного кроку) при повторі. npx playwright show-trace показує, що саме сталося в CI.
retries у CI допомагає пережити рідкісні збої, але тест, що проходить лише з другої спроби, - сигнал, а не норма: такі тести варто відстежувати й виправляти.
Скільки E2E-тестів писати: небагато - для критичних сценаріїв. Вони найповільніші й найдорожчі в підтримці; решту поведінки дешевше перевіряти на нижчих рівнях.