skip to main content

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

js

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

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

Кратко 🔗

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

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

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

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

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

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

Когда использовать 🔗

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

Какие есть инструменты 🔗

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

Рекомендации к тестам 🔗

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

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

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

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

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

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

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

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

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

Системное тестирование 🔗

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

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

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

E2E-тестирование 🔗

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

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

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

Когда использовать 🔗

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

Инструменты 🔗

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

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

Скриншотное тестирование 🔗

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

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

Когда использовать 🔗

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

Инструменты 🔗

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

Тестирование производительности 🔗

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

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

Когда использовать 🔗

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

Инструменты 🔗

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

Тестирование безопасности 🔗

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