Теория: Утверждения

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()

  Expand code

• Находите баланс между общими и специфическими проверками. Например, toBeVisible() хотя и общая проверка, но такая проверка ломается гораздо реже, чем проверка, которая смотрит на конкретный текст toHaveText(). Текст может меняться постоянно и поддерживать такие тесты сложнее из-за их хрупкости.

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