Что Такое Интеграционное Тестирование? Виды, Примеры

Многие разработчики стремятся к абстрагированию и обобщению кода путем введения дополнительных уровней абстракции. Иногда встречаются внепроцессные зависимости, обладающие свойствами как управляемых, так и неуправляемых зависимостей. Хорошим примером служит база данных, доступная для других приложений. Создание модуля как tests/common.rs также работает, но не рекомендуется, потому что средство запуска тестов будет рассматривать файл как тестовый крейт и пытаться запускать тесты внутри него. Во втором случае мы постепенно объединяем наиболее близкие по смыслу модули в группы. Второй подход требует больше времени, но с ним удобнее определять место ошибки, если тест падает.

На этапе модульного тестирования мы изучили колесо и цепь по отдельности, а теперь нужно проверить взаимодействие и узнать, точно ли колесо приводится в движение с помощью цепи. Здесь мы проверяем интеграцию цепи и звездочки колеса — дергаем за цепь и смотрим, будет ли крутиться колесо. Интеграционное тестирование проверяет работу нескольких модулей в группе. Четкая граница между классами предметной области и контроллерами помогает отличать юниттесты от интеграционных. Управляемые зависимости представляют собой внепроцессные зависимости, доступ к которым осуществляется только через ваше приложение.

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

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

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

Применяется только для тестирования API, являющейся частью более крупной системы. Автоматизированное тестирование выполняется на ранних этапах цикла разработки. Большинство процессов включало в себя передачу данных из одного модуля (чаще всего из Salesforce) во все остальные. Если начальной точкой был не SF, то информация из модуля поступала в MuleESB, а потом в SF, а оттуда во все остальные (опять же, через MuleESB). По такому же принципу мы проверим другие модули — например, API, которое передает параметры для суммирования. Таким же образом проверяются другие запчасти велосипеда — например, цепь или руль.

Виды Интеграционного Тестирования

Он указывает на то, что тест проверяет несколько единиц поведения, что, в свою очередь, ухудшает сопровождаемость теста. Например, если имеются два связанных сценария использования (допустим, регистрация и удаление пользователя). База данных — не лучший механизм для интеграции между системами, потому что она связывает эти системы друг с другом и усложняет дальнейшую их разработку.

Можно также адаптировать и инструменты для интеграционного тестирования под E2E нужды. Если вы не знакомы с тестами, мы рекомендуем сперва прочитать статью «Как и зачем писать тесты», а потом вернуться сюда. Ответить на эти вопросы можно только после интеграционного тестирования (Integration Testing). Процедура интеграционного тестирования не зависит от выбранной стратегии (“Большой взрыв”, “сверху вниз”, “снизу вверх”, “сэндвич”). Циклические зависимости увеличивают когнитивную нагрузку при попытках разобраться в коде.

Используйте это решение только в случае, если других вариантов нет. Правильнее осуществлять интеграцию через API (для синхронных взаимодействий) или шину сообщений (для асинхронных взаимодействий). При этом могут проверяться API, база данных, бизнес-логика, интеграция с внешними ресурсами. Работа над проектом продолжается, но уже можно сказать, что система функционирует надежно.

Иногда внепроцессная зависимость обладает свойствами как управляемых, так и неуправляемых зависимостей. Наблюдаемую часть такой базы следует интерпретировать как неуправляемую зависимость; заменяйте ее моками в тестах. Рассматривайте остальную часть зависимости как управляемую — проверяйте ее итоговое состояние, а не взаимодействия с ней.

Решение Проблемы Интеграционного Тестирования

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

Изоляционное тестирование (Isolation testing) – это вид тестирования, в котором компонент или модуль системы тестируется в изоляции от остальных компонентов. Основная цель изоляционного тестирования состоит в проверке функциональности, корректности и надежности отдельных компонентов системы, независимо от их взаимодействия с другими компонентами. Интеграционное тестирование снизу вверх – это стратегия, при которой сначала тестируются модули нижнего уровня. Эти протестированные модули затем используются для облегчения тестирования модулей более высокого уровня. Процесс продолжается до тех пор, пока не будут протестированы все модули верхнего уровня.

Системные и интеграционные тесты тоже можно автоматизировать и встроить в CI/CD проекта. Моки создаются с целью контролировать и проверять, как компонент взаимодействует с внешними зависимостями. При использовании моков можно установить ожидаемое поведение этих зависимостей и проверить, что компонент правильно взаимодействует с ними в рамках тестируемого сценария.

Интеграционное тестирование используется при разработке программного обеспечения (ПО) необходимо не только создать код, но и убедиться, что он работает правильно во всех условиях. Одним из уровней тестирования ПО является интеграционное тестирование, которое проверяет, как компоненты ПО работают вместе. В отличие от интеграционного тестирования, где проверяется совместная работа компонентов, изоляционное тестирование фокусируется когда применяется интеграционное тестирование на тестировании компонента в изоляции от внешних зависимостей. Для этого используются моки (mocks) или заглушки (stubs), которые эмулируют поведение внешних компонентов, чтобы сосредоточиться на функциональности и корректности самого компонента. Интеграционное тестирование является необходимым этапом в процессе разработки ПО, потому что это позволяет обнаружить ошибки и проблемы, связанные с взаимодействием компонентов.

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

Драйверы, с другой стороны, вызывают модуль для тестирования и передают ему тестовые данные. Оба этих элемента помогают проводить тестирование отдельных модулей, даже если другие модули еще не готовы. Интеграционное тестирование – это тип тестирования, при котором программные модули логически интегрируются и тестируются как группа. Типичный программный проект состоит из нескольких программных модулей, написанных разными программистами. Цель интеграционного тестирования – выявить дефекты во взаимодействии между этими программными модулями, когда они интегрированы.

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

Как Делать Заглушки?

Разбираемся как тестировать взаимодействие между частями системы. Если вы применяете подход “Большого взрыва”, все компоненты или модули интегрируются вместе, а затем тестируются. При этом объединенный набор компонентов рассматривается как единое целое. Если не все компоненты в наборе завершены, интегрировать их не получится. Как вы, возможно, помните из предыдущего конспекта «Анатомия юнит-тестов», наличие более одной секции подготовки, действий или проверки в тесте — плохой признак.

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

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

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

На первый взгляд это может показаться лишней работой, но эта работа окупается в долгосрочной перспективе. Фокусировка каждого теста на одной единице поведения упрощает понимание и изменение этих тестов при необходимости. Может использоваться для тестирования широкого спектра приложений, включая настольные, веб- и мобильные приложения. Автоматизация тестирования – непростой вопрос, который требует внимательного сопоставления всех «за» и «против».