Конспект — Урок 9: Тест зелёный — а в проде баг

Главное за урок

Третья буква AAA — Assert. Это ожидаемый результат из тест-кейса: что пользователь должен увидеть после Act. Не «галочка в конце файла» и не «код не упал».

Урок 6 находил узел. Урок 7 готовил сцену. Урок 8 кликал и заполнял. Сегодня Playwright должен подтвердить, что продукт сделал то, что обещал.

Без Assert автотест проверяет только, что шаги выполнились. Клик прошёл, fill отработал — тест зелёный. В проде поле пустое.

Практика — живой profile-flow.spec.ts. Отдельного Assert Lab нет.

Где кончается Act и начинается Assert

Ручной кейс: предусловия / шаги / ожидаемый. Assert = ожидаемый.

click и fill не гарантируют успех: сервер мог не сохранить, UI мог не обновиться. Один дымовой expect с Урока 8 — только «что-то изменилось». Сегодня проверка привязана к смыслу кейса.

Один expect — один смысл. Двенадцать матчеров на один клик — простыня: чинишь по одному, теряешь время.

await expect и забытый await

expect возвращает промис. Без await тест не ждёт проверку: идёт дальше и часто остаётся зелёным, хотя assert не выполнился.

// плохо — промис «ушёл», проверка могла не случиться
const x = expect(page.getByLabel("Имя")).toHaveValue("Анна");

// правильно
await expect(page.getByLabel("Имя")).toHaveValue("Анна");

Правило то же, что с click на Уроке 4 и 8: await перед каждым expect.

Retrying assertions — почему не sleep

Локаторный expect не сравнивает DOM один раз. Он переспрашивает, пока условие не станет true или не истечёт timeout.

UI после клика догоняет — expect ждёт. waitForTimeout(3000) лечит симптом и делает флаки: завтра страница чуть медленнее — снова красный.

Таймаут задаётся в конфиге (expect.timeout) или точечно:

await expect(page.getByRole("button", { name: "Сохранить" })).toBeEnabled({
  timeout: 10_000,
});

Не всё в Playwright — retrying. Обычный expect(2 + 2).toBe(4) сравнивает сразу. Retry — у проверок локатора и страницы (toBeVisible, toHaveURL и т.д.).

Какой матчер для чего

Смотри на экран, не в кишки React. Хорошо: текст, value, видимость, disabled. Плохо: внутренний state, точный CSS-класс, порядок вызовов API.

Видимость и DOM

toBeVisible ≠ «нашёлся в DOM». Элемент может быть attached и при этом скрыт оверлеем или display: none. Для «пользователь это видит» — toBeVisible. Для «узла больше нет» — toBeDetached или toHaveCount(0).

toBeHidden и not.toBeVisible близки, но не близнецы. toBeHidden проходит и для hidden-в-DOM, и для отсутствующего. Если смысл кейса «этого текста нет» — чаще not.toContainText / not.toBeVisible.

Текст и значения полей

Не путать: toHaveValue — то, что лежит в поле. toContainText — то, что написано на экране (чип, заголовок, ошибка). Для <input> после fill почти всегда toHaveValue.

await expect(page.getByLabel("Имя")).toHaveValue("Анна Тест");
await expect(page.getByTestId("can-help-skills")).toContainText("Playwright");

Количество

toHaveCount(0) — позитивная формулировка «ноль штук». not.toBeVisible() — «этого элемента нет на экране». Для списка чаще count; для одного узла — not.toBeVisible.

Состояние элемента

toBeEnabled / toBeDisabled — про actionability с Урока 8, только уже как проверка, не как ожидание перед кликом.

await expect(page.getByRole("button", { name: "Продолжить" })).toBeDisabled();
await page.getByLabel("Принимаю").check();
await expect(page.getByRole("button", { name: "Продолжить" })).toBeEnabled();

Атрибуты, роли, страница

await expect(page).toHaveURL(/\/pomidorqa\/?$/);
await expect(page.getByRole("link", { name: "Профиль" })).toHaveAttribute(
  "href",
  "/pomidorqa/profile",
);

toHaveClass и toHaveCSS падают от рефакторинга без бага. Если пользователь видит тот же экран — не проверяй класс .skill-chip.

Ответ API и «голые» значения

Обычный expect(user.email).toContain('@') не retrying: сравнил один раз и всё. Для экрана — локаторный expect.

Скриншот

toHaveScreenshot() — пиксельное сравнение. В этом курсе не нужно: ломается от шрифта, ретины и «сдвинулось на 2px». База — состояние UI, не картинка.

Негативные проверки: .not

Негатив — такой же assert: ожидаем, что не случилось. В Playwright это .not перед матчером.

await expect(page.getByText("Навык обязателен")).not.toBeVisible();
await expect(page.getByLabel("Имя")).not.toHaveValue("");
await expect(page.getByTestId("can-help-skills")).not.toContainText("Playwright");
await expect(page.getByRole("button", { name: "Добавить" })).not.toBeEnabled();

Типичные кейсы:

Пустой ввод: required в HTML блокирует submit — чип не появляется. Тест должен это утвердить, а не «кликнул и пошёл дальше».

.not обязателен в ДЗ этого урока: хотя бы один тест с expect(...).not.*.

expect.soft — собрать ошибки разом

Обычный expect: упал — тест остановился. Остальные проверки даже не бегут.

expect.soft: упал — пошёл дальше, в конце красный со списком. Удобно на форме: Имя, Telegram, «О себе» — чинишь все поля за один прогон.

await expect.soft(page.getByLabel("Имя")).toHaveValue("Анна");
await expect.soft(page.getByLabel("Telegram")).toHaveValue("@anna");
await expect.soft(page.getByLabel("О себе")).toHaveValue("Пишу тесты");

Не замена жёсткому assert. Если страница не та — дальше кликать бессмысленно, там нужен обычный expect. Soft — бонус, не обязательная часть ДЗ.

Антипаттерны

expect живёт в тесте, не в beforeEach и не в функции «кликни Добавить». Границы с Page Object — Урок 10.

Как подойти к домашке

1. git checkout main → git pull origin main, ветка hw9-<github-username>.
2. Дописать необходимые автотесты на профиль. Минимум 3 теста.
3. Один из них — обязательно негативный через expect(...).not.*.
4. В каждом тесте после Act есть осмысленный expect (value, текст, видимость) — не «кликнул и всё».
5. arrange-practice и booking-flow не трогать. Без хардкода email. Календарь и бронь не трогаем.
6. Все тесты зелёные по одному и пачкой → PR в main.

Ключевые тезисы для теста

• Assert — ожидаемый результат после Act, не «код не упал».
• await перед каждым expect; без await проверка может не выполниться.
• Локаторный expect переспрашивает UI — sleep перед проверкой не нужен.
• toHaveValue — поле; toContainText / toHaveText — текст на экране.
• toBeVisible — виден пользователю; toBeAttached — просто есть в DOM.
• Негатив пишется через .not (not.toBeVisible, not.toContainText, not.toHaveValue).
• toHaveCount(0) — список пуст; toBeEnabled / toBeDisabled — можно ли действовать.
• toHaveURL — навигация после submit.
• expect.soft собирает несколько ошибок; не заменяет жёсткий expect на развилке.
• Не проверяй CSS-класс и внутренний state — смотри на экран.