Если вы тестируете интерфейсные приложения, вам следует знать о пирамиде интерфейсного тестирования.

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

Пирамида внешнего тестирования

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

Идеальный набор тестов состоит из модульных тестов, нескольких тестов моментальных снимков и нескольких сквозных (e2e) тестов.

Это обновленная версия пирамиды тестирования, специфичная для тестирования интерфейсных приложений.

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

Приложение

Чтобы подробнее узнать о пирамиде интерфейсного тестирования, мы рассмотрим, как тестировать веб-приложение.

Это простое модальное приложение. Нажатие кнопки открывает модальное окно, а нажатие кнопки ОК на модальном окне закрывает модальное окно.

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

Приложение состоит из трех компонентов: компонента Button, компонента Modal и компонента App.

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

Модульные тесты

Модульные тесты тестовых модулей кодовой базы.

Они вызывают функции или модули напрямую и проверяют, возвращают ли они правильный результат.

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

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

Мелкий рендеринг означает, что мы рендерим компонент на один уровень глубже. Таким образом, мы можем быть уверены, что тестируем только компонент, наш модуль, а не дочерний компонент на несколько уровней ниже.

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

Мы не будем смотреть на код. Но спецификации наших компонентов выглядят так:

  • Модальный класс имеет активный класс, когда displayModal имеет значение true
  • У модального окна нет активного класса, если displayModal имеет значение false
  • Модальные вызовы toggleModal при нажатии кнопки успеха
  • Модальные вызовы toggleModal при нажатии кнопки удаления
  • Кнопка вызывает toggleModal при нажатии кнопки

Наши тесты выполнят неглубокий рендеринг компонентов, а затем проверит, работает ли каждая из спецификаций.

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

Модульные тесты быстрые.

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

Это делает модульные тесты полезными для разработки. При рефакторинге кода мы можем изменить код и запустить модульные тесты, чтобы убедиться, что изменения не нарушили работу компонента. Мы узнаем в течение нескольких секунд, если что-то сломаем, потому что один из тестов не удастся.

Модульные тесты являются гранулярными

Другими словами, они очень специфичны.

Если модульный тест не работает, сломанный тест расскажет нам, как и почему он не работает.

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

Но они не могут все проверить.

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

Снимки тестов

Моментальные тесты - это тесты, которые делают снимок вашего визуализированного компонента и сравнивают его с предыдущим изображением вашего компонента.

Лучше всего писать тесты снимков на JavaScript с помощью Jest.

Вместо того, чтобы делать снимок визуализированного компонента, Jest делает снимок разметки визуализированного компонента. Это делает тесты моментальных снимков Jest намного быстрее, чем традиционные тесты моментальных снимков.

Чтобы зарегистрировать тест снимка в Jest, вам нужно добавить что-то вроде кода ниже:

const renderedMarkup = renderToString(ModalComponent)
expect(renderedMarkup).toMatchSnapshot()

После того, как вы зарегистрируете снимок, обо всем остальном позаботится Jest. Каждый раз, когда запускаются модульные тесты, он восстанавливает моментальный снимок и сравнивает его с предыдущим моментальным снимком.

Если код изменяется, Jest выдает ошибку и предупреждает, что разметка изменилась. Затем разработчик может вручную проверить, не был ли случайно удален ни один класс.

В приведенном ниже тесте кто-то удалил класс modal-card-foot из класса <footer>.

Моментальные тесты - это способ проверить, что в стиле или разметке компонента ничего не изменилось.

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

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

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

Теперь у нас есть модульные тесты и тесты моментальных снимков, пришло время взглянуть на сквозные (e2e) тесты.

Сквозные тесты

Сквозные (e2e) тесты - это тесты высокого уровня.

Они выполняют те же действия, что и мы, если бы мы тестировали приложение вручную.

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

Мы можем написать сквозной тест, который пройдет через это путешествие. Тест откроет браузер, перейдет на веб-страницу и выполнит каждое действие, чтобы убедиться, что приложение работает правильно.

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

Есть несколько способов написать сквозные тесты для приложений JavaScript. Существуют такие программы, как test cafe, которые записывают ваши действия в браузере и воспроизводят их как тесты.

Есть также такие проекты, как nightwatch, которые позволяют писать тесты на JavaScript. Я бы рекомендовал использовать такую ​​библиотеку, как nightwatch. Его легко понять, и тесты выполняются быстрее, чем записанные тесты.

Тем не менее, тесты nightwatch все еще относительно медленные. Для выполнения набора из 200 модульных тестов требуется несколько секунд, для набора из 200 сквозных тестов требуется несколько минут.

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

Заключение

Чтобы эффективно протестировать веб-приложения на основе интерфейсных компонентов, вам необходимо провести три типа тестов. Модульные тесты, тесты моментальных снимков и тесты e2e.

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

Общий модульный тест составит основную часть ваших тестов, у вас будет несколько тестов моментальных снимков и несколько тестов e2e.

Если вы будете следовать пирамиде внешнего тестирования, вы создадите поддерживаемые веб-приложения с помощью потрясающих наборов тестов.

Вы можете увидеть пример репозитория приложения с тестами моментальных снимков, модульными тестами и сквозными тестами на GitHub.