Простой

6 мин

11K

Начинаете писать E2E-тесты? Думаете, нужно просто открыть страницу, нажать кнопку и написать expect?

Разберем на примере Playwright, почему отчёт может быть зелёным, но бесполезным!

Сразу к делу! Ошибка 1. Проверка интерфейса без проверки взаимодействия

Ошибка распространенная, но не примитивная. Вот вам вредный совет, как проверить, что после нажатия на кнопку все сохраняется:

await page.getByRole('button', { name: 'Сохранить' }).click();
await expect(page.getByText('Сохранено')).toBeVisible();

Все правильно, не так ли? Мы видим, что все сохранилось, исходя из надписи "Сохранено".

Но где гарантия, что это сообщение показывается после реального ответа сервера? Где гарантия, что фронт здесь вообще опирается на реальный ответ сервера? В этом тесте мы всего лишь подтвердили реакцию интерфейса, но не проверили, что данные реально отправились и изменились.

Как будет правильнее?

const responsePromise = page.waitForResponse(response =>
  response.url().includes('/api/profile') &&
  response.request().method() === 'PUT'
);

await page.getByRole('button', { name: 'Сохранить' }).click();

const response = await responsePromise;
expect(response.status()).toBe(200);

await expect(page.getByText('Сохранено')).toBeVisible();

Ошибка 2. Ожидание события создается после действия

Каждый раз, когда мы хотим поработать с новыми вкладками, скачиванием файлов, переходами на другие страницы и т. д., есть вариант, что мы напишем так:

await page.getByRole('link', { name: 'Открыть договор' }).click();

const newPage = await page.context().waitForEvent('page');

На первый взгляд код выглядит логично. Сначала нажали на ссылку, потом ждём новую страницу. Но проблема в том, что новая вкладка могла открыться сразу после клика. В таком случае тест начинает ждать событие уже после того, как оно произошло.

Локально такой тест вполне может пройти, потому что все удачно совпало по времени или медленнее работает, но едва ли он будет полностью стабилен, в том числе когда начнем запускать его в CI.

Playwright умеет ждать такие события, но важно поставить ожидание до действия, которое это событие вызывает. В документации Playwright для таких случаев используется именно такой порядок: сначала создаётся Promise ожидания, потом выполняется действие, потом результат события забирается через await.

Правильный пример:

const pagePromise = page.context().waitForEvent('page');

await page.getByRole('link', { name: 'Открыть договор' }).click();

const newPage = await pagePromise;
await newPage.waitForLoadState();

await expect(newPage).toHaveTitle(/Договор/);

Ошибка 3. Некорректный выбор локатора

Проблема не всегда в том, как мы ищем элемент. Иногда проблема в том, насколько однозначно мы его ищем. Я с этим обычно сталкиваюсь при отладке, иногда бывает, что тест кликает вообще не на тот элемент, который имелся ввиду.

Особенно сложно может быть бороться с этой проблемой, если на фронте не на что опереться при выборе локатора. И в такой ситуации мы уже начинаем выбирать не хороший локатор, а наименее плохой. Цепляться за текст рядом, порядок элементов, вложенность или ближайший контейнер, только вот чем больше происходит таких компромиссов, тем выше вероятность, что при следующем изменении интерфейса, придется фиксить тест.

И, честно говоря, здесь можно было бы так же сказать, вот плохой пример:

await page.getByRole('button', { name: 'Сохранить' }).click();

Продолжить, что он плох не потому, что getByRole использовать нельзя, а потому что контекст не указан (ведь тест не указывает какую именно кнопку "Сохранить" можно нажать).

Добавить, что область поиска лучше сузить подобным образом:

const profileForm = page.getByTestId('profile-form');

await profileForm.getByLabel('Телефон').fill('+79990000000');
await profileForm.getByRole('button', { name: 'Сохранить' }).click();

Чтобы, по крайней мере, искать кнопку не на всей странице, а внутри конкретной формы профиля.

Но, честно говоря, если у вас регулярно появляются проблемы с тем, чтобы выбрать локатор, который можно идентифицировать однозначно, это уже не проблема тестирования и тестов. Это сигнал, что интерфейс плохо подготовлен для устойчивого тестирования.

И в таком случае я рекомендую не маскировать проблему сложными локаторами, мучаясь в одиночку, а связаться с разработчиками и договориться о нормальных атрибутах на фронте.

Ошибка 4. Тесты изолированы в браузере, но не изолированы в данных

Playwright создаёт отдельный браузерный контекст для каждого теста: отдельные cookies, localStorage, sessionStorage и похожее на новый профиль браузера окружение. Но данные в базе, пользователи, заказы и заявки не изолированы.

Если вы не позаботитесь о том, чтобы это сделать, тесты параллельно у вас работать не будут. Будут проходить по одному, но пачкой запускать не получится, и это очень неудобно.

Пример проблемы:

test('создаёт заявку', async ({ page }) => {
  await createApplication(page, 'test@mail.ru');
});

test('редактирует заявку', async ({ page }) => {
  await openApplication(page, 'test@mail.ru');
  await editApplication(page);
});

Здесь пример простой, но все равно видно, что второй тест зависит от данных первого. Если изменится порядок, тест упадет. Если первый тест не создал заявку из-за другой ошибки, второй тоже упадёт, хотя его собственная проверка может быть ни при чём. Либо же если параллельно мы запустим другой набор тестов с тем же пользователем, начнутся конфликты.

Как лучше?

test('редактирует заявку', async ({ page, request }) => {
  const email = `user-${crypto.randomUUID()}@test.local`;

  await request.post('/api/test-data/applications', {
    data: {
      email,
      status: 'new',
    },
  });

  await page.goto('/applications');

  await page.getByText(email).click();
  await page.getByRole('button', { name: 'Редактировать' }).click();
  await page.getByLabel('Комментарий').fill('Проверка изменения заявки');
  await page.getByRole('button', { name: 'Сохранить' }).click();

  await expect(page.getByText('Заявка обновлена')).toBeVisible();
});

Ошибка 5. force: true скрывает настоящую проблему интерфейса

Кнопка на странице есть, локатор ее находит, но тест падает, потому что Playwright не может нажать на элемент.

Частый вариант решения проблемы:

await page.getByRole('button', { name: 'Оплатить' }).click({ force: true });

И это действительно помогает, но проблема в том, что force: true не должен превращаться в способ не разбираться, почему обычный клик не прошёл.

Что тут не так? Перед кликом Playwright проверяет, можно ли взаимодействовать с элементом: виден ли он, стабилен ли, не перекрыт ли другим элементом, получает ли события мыши. Если проверка не прошла, может быть два варианта.

1. Тест нашел реальную проблему интерфейса. Например, кнопку перекрывает загрузчик, баннер, модальное окно или невидимый слой. В этом случае пользователь тоже может не суметь нормально продолжить сценарий, а force: true просто спрячет дефект.

2. Для пользователя сценарий работает, но Playwright видит техническое перекрытие. Например, поверх кнопки лежит декоративный элемент, пустой слой, иконка или часть компонента, которая не мешает ручному клику, но мешает автоматическому действию.

Поэтому здесь ошибка не в коде, а в том, что его иногда пишут без диагностики.

Как здесь логичнее поступить?

// Используем force, потому что кнопку технически перекрывает декоративный слой.
// Руками сценарий проходит
await page.getByRole('button', { name: 'Оплатить' }).click({ force: true });

Если тесты проходят, но не ловят ошибки, проблема часто не в инструменте. Надеюсь, для вас здесь нашлось что-то полезное и интересное, приходите еще :)

Если хочется разобрать похожие ошибки на практике — записывайтесь на открытые уроки OTUS про UI-автотесты, API-проверки и ИИ в тестировании. Уроки бесплатные, ведет преподаватели-практики, можно будет задать свои вопросы.

• 21 мая, 20:00. «Суперсилы Kotlin для удобных UI-автотестов». Записаться

• 4 июня, 20:00. «API под контролем: тестирование сервисов с помощью Postman». Записаться

• 16 июня, 20:00. «ИИ в автотестах: помощник или угроза?». Записаться