Как тестирование соединения со сторонним API вписывается в непрерывную интеграцию?

Question

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

Формальная сборка сегодня не удалась, поскольку при попытке подключиться к стороннему API-интерфейсу тест получил ошибку 500.

Имеет ли смысл тестировать подобную ситуацию?

Answer 1

На мой взгляд, интеграционные тесты могут быть неудачными, если сторонняя организация (db, webservice и т. Д.) Недоступна.Если вы не хотите проверять саму интеграцию и только простую функциональность, вы можете смоделировать результаты вашего API и протестировать их.В этом сценарии ваш тест больше не зависит от доступности третьей стороны.

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

Answer 2

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

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

• Напишите модульные тесты класса обслуживания так, чтобы

  • , если обслуживание прекращенопроисходит ошибка, тесты проходят, но регистрируются ошибки.

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

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

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

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

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