Пирамида тестирования иллюстрирует различные типы тестов и их взаимосвязь друг с другом. Разработчики могут быть довольно догматичными и иметь очень категоричные мнения когда речь идет о тестировании, но помните, что, несмотря на то, какие термины и аргументы они используют, в конечном итоге “важно не то, как вы это называете, а то, что это делает” – Gojko Adzic.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
Unit-тесты
В основании пирамиды находятся модульные тесты. Они находятся в самом низу, поскольку являются фундаментом, на который опираются остальные тесты.
Как видите, они занимают наибольшую площадь пирамиды, и, как правило, этих тестов пишется больше всего.
Юнит-тесты предназначены для тестирования отдельной “единицы” в приложении. Это означает, что они не должны зависеть от других частей системы или приложения. Например, можно протестировать всего одну функцию.
При написании модульных тестов необходимо рассматривать тестируемую функцию как “черный ящик”. Вас не интересует логика внутри функции. Вас интересует только то, что вы ожидаете определенный результат при определенных условиях. Таким образом, вы всегда можете рефакторить внутреннюю часть или тело функции, не нарушая тестов.
То есть, опять же, вы просто проверяете, что при определенном наборе входных данных в этой функции мы получаем определенный результат. То, как это работает внутри, не имеет значения для целей тестирования.
Интеграционные тесты
Интеграционное тестирование направлено на то, чтобы отдельные части или блоки приложения работали вместе в соответствии с ожиданиями.
В отличие от модульных тестов, которые всегда должны быть независимыми, интеграционные тесты являются принципиально зависимыми. Их цель – проверить корректность работы взаимосвязи различных частей системы.
Таким образом, различие между модульными и интеграционными тестами заключается в том, что модульные тесты тестируют отдельные части приложения, а интеграционные тесты тестируют части приложения, связанные друг с другом, но никогда не изолированные друг от друга.
Компонентные тесты
Современные библиотеки фронтенда позволяют создавать приложения с помощью компонентов. Компонент – это небольшой функциональный фрагмент пользовательского интерфейса. На самом низком уровне компонентом может быть такая простая вещь, как кнопка, ярлык или поле ввода. Затем можно начать объединять небольшие компоненты в более крупные для создания более сложной функциональности, например, формы входа в систему или сводки заказов в корзине.
Компонентное тестирование – это еще один вид тестирования, который позволяет тестировать компонент изолированно от остальной системы. Благодаря этому компонентные тесты обладают многими теми же характеристиками, что и модульные и интеграционные тесты. Как правило, их проще настроить и быстрее выполнить. Поскольку в них меньше движущихся частей, они более устойчивы к сбоям.
Компонентные тесты позволяют тестировать сложный пользовательский интерфейс вне его местоположения в приложении. Однако, поскольку они не взаимодействуют с остальной частью системы, на них нельзя положиться для оценки общего состояния приложения, и именно здесь на помощь приходят сквозные тесты.
Сквозные тесты
Эти тесты пишутся для проверки всего, что запускается в браузере. Цель этих тестов – имитировать действия реального пользователя.
Например, можно написать один тест, который регистрирует новую учетную запись, входит в эту учетную запись, покупает товар и затем выходит из нее. Таким образом, можно убедиться, что все уровни приложения работают правильно.
Конечные тесты (End-to-end, E2E) часто заменяют интеграционные тесты, поскольку по сути проверяют одно и то же. Однако тесты E2E имеют все большее преимущество и ценность по сравнению с интеграционными тестами, поскольку они проверяют реальное взаимодействие пользователей внутри приложения.
Перевод статьи «What is the Testing Pyramid?».