Руководство по контрактному тестированию

Содержание:

• Обзор
• Что такое контрактное тестирование
• Зачем нужно контрактное тестирование
• Преимущества
• Важные термины
• Когда использовать
• Типы
• Примеры использования
• Способы выполнения
• Инструменты
• Ограничения
• Часто задаваемые вопросы (FAQ)

Обзор

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

Уже десять лет технологические гиганты, включая Amazon, Facebook и Google, используют контрактное тестирование для тестирования микросервисов. Но это не означает, что оно характерно только для высокотехнологичных транснациональных компаний. Любой бизнес, работающий с приложениями, может получить от него пользу.

Друзья, подпишитесь на наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Что такое контрактное тестирование?

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

Его цель – убедиться, что передаваемые сообщения соответствуют общему пониманию в хорошо документированном контракте.

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

Зачем нужно контрактное тестирование

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

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

Сквозные интегрированные тесты (наиболее распространенный тип таких тестов) имеют ряд существенных недостатков. Поскольку они проходят через разные системы, тестировщики обычно выполняют их последовательно, что занимает много времени.

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

Ситуация может еще больше усложниться из-за большего количества тестируемого кода, а вместе с этим происходит экспоненциальное замедление выполнения наборов тестов. Это приводит к засорению релизов в конвейерах автоматизации тестирования, что приводит к отсутствию масштабируемости. Разумеется, когда процесс поиска ошибок занимает определенное время и обнаруживает их на более поздних стадиях, затраты могут расти бесконечно, даже в современной agile-экосистеме.

Именно здесь на помощь приходит контрактное тестирование. Эта методология обеспечивает безупречную связь и высокую совместимость между двумя независимыми системами, такими как микросервисы. Самое приятное в этом тестировании то, что команда QA может достичь тех же результатов, что и при интеграционном, только без всех сопутствующих сложностей.

Преимущества контрактного тестирования

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

Вот некоторые из них:

• Облегчает независимые релизы и уверенную непрерывную доставку.
• Такие тесты выполняются быстро и требуют минимального обслуживания, что приводит к высокой рентабельности инвестиций. Поскольку разработчики могут легко и оперативно экспериментировать с различными тестами, понимать различные требования и определять конечные точки, это избавляет их от длительных процессов и многократного возвращения назад.
• Еще одним фактором, способствующим высокой скорости, является возможность создания изолированной среды кодирования вместо развертывания среды разработки.
• Контрактные тесты повторяемы и хорошо масштабируемы.
• Потребители могут легко понять поведение сервиса с помощью макетов и тестов, которые облегчают обучение. Это также снижает затраты на инфраструктуру и эксплуатационные расходы. К тому же, поскольку старые версии сервисов всегда под рукой, тестирование новых улучшений не потребует дополнительных затрат.
• Тесты могут запускаться на реальных и макетных системах для проверки соответствия ответов и сертифицирования совершенно новых контрактов.
• Контрактное тестирование сокращает продолжительность цикла обратной связи, устраняя время ожидания результатов регрессии. Благодаря изолированной среде разработчики могут быстро обнаружить проблемы бизнес-процессов и функциональностьи.
• Можно легко повторно использовать тестовые случаи и артефакты, что способствует ускорению сроков выполнения тестов для различных сценариев тестирования.
• Перед отправкой кода контрактные тесты запускают на машинах разработчиков, чтобы выявить локальные ошибки.
• Контрактное тестирование позволяет точно определить, какие поля интересуют пользователей, и удалить неиспользуемые. В результате добавление новых полей в API провайдера оказывается довольно простым и не затрагивает пользователя.

Важные термины контрактного тестирования

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

• Потребитель: од потребителем обычно понимается клиент, который желает получать данные по контракту между двумя объектами. Этот компонент инициирует HTTP-запрос для другого компонента.
• Поставщик: Под ним понимается организация, подобная API, предлагающая на сервере данные, необходимые клиенту. Провайдер отвечает за ответ на инициированный потребителем HTTP-запрос.
• Файл контракта: Файл контракта – это файл, содержащий JSON-ответы и запросы в потребительских тестах в сериализованной форме.
• Соглашение об оказании услуг: Это обязательство со стороны поставщика услуг, которое обещает возвращение определенного ответа, как только потребитель выполнит запрос.

Когда использовать контрактное тестирование?

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

Наиболее распространенные варианты его использования включают:

• Мониторинг рабочего процесса потребителя на предмет нарушений.
• Определение наличия ошибок или дефектов в конфигурации сервиса.
• Поддержание безопасности соединений даже при изменении конфигурации сервиса производителем.

Типы контрактного тестирования

Существует два основных типа контрактных тестов – тесты, ориентированные на потребителя, и тесты, ориентированные на поставщика. Давайте рассмотрим оба типа.

• Ориентированные на потребителя (Consumer-driven): Под этим понимается паттерн, в котором тестируются только те части коммуникации, которые реально использует потребитель. То есть поведение поставщика, не используемое текущими потребителями, может изменяться, не вызывая никаких сбоев в тестах.
• Управляемые поставщиком(Provider-driven): Подразумевает использование метода в контексте приложения одного поставщика, а не интеграции. В этом случае под контрактным тестированием обычно понимается процесс, обеспечивающий соответствие поведения поставщика хорошо документированному контракту. Например, это может быть документ OpenAPI.

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

Примеры использования контрактного тестирования

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

• Микросервисы: Это один из распространенных сценариев использования. В большинстве организаций к управлению версиями программного обеспечения не относятся серьезно до тех пор, пока не закончится жизненный цикл разработки программного обеспечения. То же самое относится и к реализации микросервиса. Поскольку микросервисы, как правило, состоят из множества компонентов, их сопровождение может становиться все более затруднительным по следующим причинам:
  • Неспособность интегрироваться, отсутствие документации и версий.
  • По мере масштабирования тестирования сложность возрастает.
• API: Реализовав контрактные тесты, производители API могут синхронизироваться с потребителями.
  • Потребители готовят все тестовые примеры и сохраняют результаты в компьютерных программах.
  • Производитель проверяет тестовый пример. По завершении процесса верификации потребитель общается с производителями API.

В целом контрактное тестирование может помочь вам в следующих вопросах

• Установление правильного взаимодействия между производителем и потребителем.
• Контроль ответов потребителей и производителей.
• Повышение совместимости микросервисов.

Способы проведения контрактного тестирования

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

1. Тестирование на развернутом сервисе: Этот вариант целесообразен для того, чтобы убедиться, что сервисы (например, API-провайдер и клиент) могут взаимодействовать друг с другом после внесения изменений.
2. Тестирование на фиктивном сервисе: Тестирование на макетном объекте может стать полезной альтернативой трудоемким интеграционным тестам. Хотя оно не может полностью заменить интеграционное тестирование, контрактные тесты все же являются важной частью процесса разработки.
3. Тестирование будущего сервиса: Если вы работаете в команде, придерживающейся принципов разработки, управляемой тестами (TDD – test-driven development), то написание тестов по ходу работы может помочь вам в обсуждении и принятии проектных решений. После того как конечные точки будут написаны, тесты пройдут и подтвердят, что поставщик выполнил свой контракт.

Инструменты для тестирования контрактов

• Pact: Это инструмент командной строки, который обеспечивает более быстрое время обратной связи. Pact помогает производителям и потребителям легче общаться между собой.
• Spring cloud contract: Этот инструмент может использоваться с виртуальной машиной Java (JVM), но его также можно расширить для работы с другими средами. Spring cloud contract в основном помогает выполнять тесты контрактов, управляемых производителями.
• Hoverfly: Hoverfly написан на языке Go и имеет встроенную поддержку Java, что позволяет запускать его внутри тестов JUnit. Его можно использовать для тестирования как REST API, так и вызовов между микросервисами.

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

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

Ограничения контрактного тестирования

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

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

Единственный способ борьбы с этими ограничениями – это частое обновление контрактов. Для этого в процессе тестирования контрактов все команды разработчиков должны четко определять новые требования при изменении поведения или функциональности микросервиса.

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

Заключение

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

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

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

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

Часто задаваемые вопросы (FAQs)

Является ли контрактное тестирование функциональным тестированием?

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

Является ли контрактное тестирование тем же самым, что и тестирование API?

Контрактное тестирование – это быстрая и простая форма тестирования API, которая оценивает содержание и структуру запросов и ответов API.

Что такое контрактное тестирование?

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

Что такое тестирование контрактов API?

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

Что такое контрактное тестирование в программном обеспечении?

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

Что такое контрактное тестирование в микросервисах?

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

Какой пример тестирования контрактов API?

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

Кто отвечает за тестирование контракта?

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

Перевод статьи «Contract Testing Tutorial: Comprehensive Guide With Best Practices».