Зарегистрируйтесь, чтобы продолжить обучение

Утверждения Тестирование с Playwright

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

Проверка данных

Сюда входят проверки встроенных типов данных, строк, объектов, булевых значений и так далее. Такие проверки чаще используются в юнит-тестировании и интеграционном.

const hasErrors = false
expect(hasErrors).toBe(true)

expect('hexlet').toContain('hex')
expect({ project: 'hexlet' }).toEqual({ project: 'hexlet' })

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

Проверки элементов в браузере

Практически все эти проверки работают с локаторами и несколько со страницей целиком. Они проверяют состояния элементов, видимость, редактируемость, фокусировку, отметку, содержание текста, наличие каких-то атрибутов и так далее. С этими проверками вы будете встречаться чаще всего.

const locator = await page.getByRole('textbox')
await expect(locator).toBeVisible()
await expect(locator).toContainText('Приплыли')

Подобных проверок много, но на практике нужны только несколько основных. Остальные можно подсматривать в документации по необходимости.

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

Отрицание

Независимо от типа проверки, механизм expect() поддерживает отрицание. Любую проверку можно инвертировать вызвав свойство not:

expect('hexlet').not.toContain('box')

const locator = await page.getByRole('textbox')
await expect(locator).not.toContainText('Приехали')

Как правильно составлять проверки?

  • Старайтесь проверять внешнее проявление действий на странице, а не внутренние детали. Например, toBeVisible() отличная проверка, а toHaveCSS() вряд ли. Хотя ситуации бывают разные, но, в среднем, внутренности лучше не трогать.

  • Всегда заменяйте проверки данных, на проверку элементов на странице если это возможно. Проверку данных сложно отлаживать, если она базируется на параметрах элементов страницы.

    // 👎 хуже вывод и менее удобная отладка
    expect(await page.getByText('Хекслет').isVisible()).toBe(true)
    
    // 👍
    await expect(page.getByText('Хекслет')).toBeVisible()
    
  • Находите баланс между общими и специфическими проверками. Например, toBeVisible() хотя и общая проверка, но такая проверка ломается гораздо реже, чем проверка, которая смотрит на конкретный текст toHaveText(). Текст может меняться постоянно и поддерживать такие тесты сложнее из-за их хрупкости.

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


Дополнительные материалы

  1. playwright.dev

Для полного доступа к курсу нужен базовый план

Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.

Получить доступ
1000
упражнений
2000+
часов теории
3200
тестов

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

  • 130 курсов, 2000+ часов теории
  • 1000 практических заданий в браузере
  • 360 000 студентов
Отправляя форму, вы принимаете «Соглашение об обработке персональных данных» и условия «Оферты», а также соглашаетесь с «Условиями использования»

Наши выпускники работают в компаниях:

Логотип компании Альфа Банк
Логотип компании Aviasales
Логотип компании Yandex
Логотип компании Tinkoff