Интеграционное и системное тестирование

Юнит-тесты, как правило, занимают наибольший объём тестов в проекте. Ограничение же юнит-тестов в том, что они не проверяют, как модули работают в связи друг с другом.

Для решения этой проблемы разработчики используют интеграционное и системное тестирование.

Интеграционное тестирование проверяет работу нескольких модулей в группе. Системное тестирование проверяет программную систему полностью.

Они решают проблему, которая остаётся после покрытия кода юнит-тестами — проверяют, как модули работают в связи друг с другом. Системное тестирование более обширно и само делится на несколько видов тестов по их типу и назначению.

Системные и интеграционные тесты тоже можно автоматизировать и встроить в CI/CD проекта.

Интеграционные тесты проверяют, как два или несколько модулей взаимодействуют друг с другом. Мы, как правило, всё ещё не поднимаем весь проект полностью, а проверяем работу отдельных фич.

Например, проверка одного из сценариев регистрации на бэкенде может быть описана в виде интеграционного теста. Такая проверка затронет и API-эндпоинты, и контроллеры, и общение в базой данных.

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

Среди самых популярных инструментов можно назвать:

• Testing Library
• Enzyme

Выбрать подход

Есть два подхода к интеграции модулей для тестирования: «большой взрыв» и «инкрементальная интеграция». В первом подходе мы объединяем все модули, а затем проверяем сценарии.

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

Определить критические фичи

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

Подготовить тестовые данные

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

Подготовить заглушки и драйверы

Заглушки и драйверы похожи на стабы и моки. Заглушка вызывается тестируемой группой модулей — проверяет «выход» группы; а драйвер вызывает тестируемую группу — подаёт сигнал на «вход».

Системное тестирование — это целый класс тестов. Их объединяет общий признак: они тестируют программную систему полностью.

Их много, но мы выделим самые часто используемые:

• End-to-end тесты;
• скриншотные тесты;
• тесты безопасности;
• тесты производительности.

End-to-end (E2E) тесты — помогают нам имитировать, как пользователи будут работать с нашей программой.

Обычно такие тесты описывают сценарий для теста в терминах действий пользователя, например, в браузере:

• зайти на такую-то страницу;
• нажать такую-то кнопку;
• увидеть такой-то текст.

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

Для описания таких сценариев у нас тоже богатый набор инструментов:

• Puppeteer
• Cypress
• Playwright
• Selenium
• WebDriver.IO
• Nightwatch

Можно также адаптировать и инструменты для интеграционного тестирования под E2E нужды.

Скриншотным тестированием мы проверяем регрессии пользовательского интерфейса. Сперва мы делаем скриншот-эталон, с которым потом сравниваем интерфейс после изменений.

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

Когда мы хотим проверить, что UI остался неизменным после изменения кода.

Некоторые из E2E-инструментов содержат и функциональность для скриншотного тестирования:

• Puppeteer
• Playwright

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

Мы также сперва делаем эталонные замеры, с которыми затем сравниваем показатели после изменений кода.

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

Мы можем использовать как встроенные в браузер инструменты, так и отдельные сервисы:

• jsperf
• Lighthouse
• performance в JS

Это больше относится к бэкенду, но иногда такие тесты пишут и для фронтенд-кода тоже. Чаще всего во фронтенде проверяют экранирование пользовательского ввода, защищённость куки и запросы к API.