Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

Для начала внедрения тестирования контрактов существует множество хороших ресурсов, которые помогут вам с практической стороной ваших проблем. Скажем, если вы работаете с Pact, у него есть документация и отличное сообщество в Slack – они помогут вам найти ответы на многие вопросы.

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

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

Решит ли тестирование контрактов наши проблемы?

Это крайне важный вопрос, и для ответа нужно сформулировать ответ на другой вопрос: «А что у нас вообще за проблема?» Внедрение тестирования контрактов, особенно ориентированного на потребителя, требует значительного времени и усилий, а тестирование изменится как на техническом, так и на организационном уровне.

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

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

Если ваш контекст соответствует этим условиям, тогда тестирование контрактов, возможно, решит вашу проблему (никаких гарантий), и с ним стоит познакомиться подробнее.

Какой подход к тестированию контрактов применить?

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

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

С чего начать?

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

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

• Какая интеграция – ваша головная боль? То есть какая интеграция уже страдала от проблем, или вызовет серьезные трудности, если проблемы возникнут? (сразу кажется, что тестирование должно исходить из рисков, правда? Кто бы мог подумать!)
• Если вы хотите попробовать ориентированное на потребителя тестирование контрактов, то есть ли у вас интеграции, пересекающие командные границы? В смысле, существует ли ситуация, где потребитель и поставщик разрабатываются разными командами, которые взаимодействуют друг с другом? Повторюсь, в контрактном тестировании мало смысла, если вся разработка ведется силами одной команды – шанс проблем с коммуникацией или пониманием, ведущих к проблемам интеграции, тут намного ниже. Если уж это необходимо, начните с интеграции, где и поставщик, и потребитель разрабатываются внутри одной команды (сопротивления будет меньше), но учтите, что толк будет, вероятно, небольшой.
• Если вы выбрали двустороннее тестирование контрактов, то внешний провайдер вроде платежной системы или другого SaaS-сервиса – отличный кандидат для проверки BDCT. Крайне, крайне маловероятно, что они поучаствуют в ориентированном на потребителя тестировании контрактов, но у них наверняка есть спецификация OpenAPI, которую можно использовать для BDCT – эти спецификации нужно приложить к вашим потребительским контрактам и увидеть несоответствия, а значит, потенциальные проблемы.

Кто будет этим заниматься?

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

Возможно, сперва стоит поработать над этим…

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

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

Когда прогонять тесты?

Если ваши тесты не участвуют в пайплайне, то существуют ли они вообще?

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

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

И все?

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

Обсудить в форуме