Теория: Ожидания (Matchers)

Тестовые фреймворки Jest и Vitest идут со своим набором матчеров, для проверки разных кейсов. Все они крутятся вокруг разных типов данных, то есть с их помощью мы проверяем строчки, объекты, массивы, их структуру и содержимое.

const can = {
  name: 'pamplemousse',
  ounces: 12,
}

describe('the can', () => {
  test('has 12 ounces', () => {
    expect(can.ounces).toBe(12)
  })

  test('has a sophisticated name', () => {
    expect(can.name).toBe('pamplemousse')
  })
})

Технически то же самое можно делать и при e2e-тестировании, проверяя содержимое элементов.

test('main', async () => {
  // Тут тест

  // Проверка содержимого
  expect(document.body.textContent).toContain('user 1, you are up!')

  // Проверка атрибутов
  const button = screen.getByText('Click Me')
  expect(button.hasAttribute('disabled')).toBe(true)

  const element = screen.getByText('Hello, world!')

  // Проверка классов
  expect(element.classList.contains('my-class')).toBe(true)
  // Проверка стиля
  expect(element.style.color).toBe('red')

  // Проверка видимости
  expect(window.getComputedStyle(element).visibility).toBe('visible')
})

Но у такого подхода есть ряд недостатков. Во-первых, эти проверки более сложные, требуют использования разных элементов, свойств, методов window, взаимодействия с атрибутами и т.п. Это сложно запомнить и все делают по-разному. В некоторых случая придется использовать комбинацию проверок. Во-вторых, стандартные проверки не очень помогают при отладке, так как ничего не знают про контекст. Например, там где мы проверяем toBe(true) в случае ошибки сообщение выглядит как: ожидался true, но пришел false. Не очень помогает, да?

Для решения этих проблем, разработчики Testing Library создали библиотеку jest-dom, которая добавляет несколько десятков матчеров, закрывающих все потребности при работе с DOM. Подробнее про них можно посмотреть в официальной документации, а здесь мы рассмотрим несколько примеров. Вот как будет выглядеть код выше, с использованием этих матчеров:

test('main', async () => {
  // Тут тест

  // Проверка содержимого
  expect(document.body).toHaveTextContent('user 1, you are up!')

  // Проверка атрибутов
  const button = screen.getByText('Click Me')
  expect(button).toBeDisabled()

  const element = screen.getByText('Hello, world!')

  // Проверка классов
  expect(element).toHaveClass('my-class')
  // Проверка стиля
  expect(element).toHaveStyle({ color: 'red' })

  // Проверка видимости
  expect(element).toBeVisible()
})

Результат получился более коротким, единообразным и читаемым. К тому же, в случае ошибок, сообщения будут гораздо более полезными.

Что и как стоит проверять?

Такое разнообразие проверок порождает вопрос, а как лучше тестировать? И действительно, e2e-тесты легко написать хрупкими завязываясь на несущественные детали, при этом мы все равно не можем обеспечить гарантированную работоспособность и нужный внешний вид. Это значит, что наша основная задача, найти минимальный набор критических частей и работать только с ним.

Начнем с внешнего вида. Стоит ли тестировать размеры, цвета и другие стилистические вещи? Почти всегда бессмысленно. На работоспособность это влияет мало, а весь внешний вид все равно не проверить. Мы можем убедиться что цвет правильный, но нужный блок в каком-то браузере вылез за экран из-за ошибки верстки. Если мы и это попробуем протестировать, то на тесты мы будем тратить в десятки раз больше времени, чем на саму функциональность. Поэтому такие вещи проще проверять вручную, все равно кто-то смотрит на изменения. И даже если возникнет ошибка, то она, почти наверняка, мало на что влияет и может быть быстро исправлена.

Однако, существуют ситуации, когда визуальные тесты имеют смысл и, обычно, такие тесты основаны на сравнении скриншотов. Это отдельная тема, которая не связана с тестированием на Testing Library.

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

Третий уровень самый главный, здесь мы проверяем работоспособность. Изменения после событий, отправка форм, клики по кнопкам и тому подобное. В этом случае нас интересует то, что произойдет, отобразится какой-то блок, какой-то скроется, произойдет переход на страницу и так далее.

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