testomat.io управление авто тестамиВсем привет. Какие подходы используете для тестирования интеграции с внешними сервисами? Всем известно, что для тестирования бэкенда лучшей практикой является замокать все внешние зависимости, что бы тесты были более стабильными и быстрыми. Но что делать с интеграцией с внешними сервисами? Какие существуются подходы к данному виду тестирования? И на какой стадии пайплайна должны запускаться эти тесты? Или лучше сделать отедльной сборкой и запускать по расписанию?
Замокать внешние сервисы - очевидно =) Но ближе к релизу, в идеале, протестировать честную интеграцию, если есть такая возможность.
В этом и вопрос - как тестировать интеграцию с внешними сервисами. Внешние сервисы ведь могут изменяться, могут быть недоступными и т.д. и хотелось бы быть уверенным, что всё работает хорошо и знать точно когда, например, что то поменялось в апи.
e2e тесты и обработка результатов
так-то должна быть тестовая система, близкая к продуктовой, у которой настроены интеграции с другими тестовыми системами, шинами и так далее
на одном проекте мы засылали сообщение и ответ на него, а в тестах самих проверяли логирование по пути и что сообщение такое, какое ожидалось
Прежде всего надо осознать, что такое system under test. Ты тестируешь конкретно свой компонент. Только свой код важен. Следовательно, надо замокиповать все внешние апи, не относящиеся к твоему проекту, даже внешние сервисы, потому что они никак не относятся к твоему проекту организационно, это левые люди.
Предположим, что ты найдешь багу в их сервисе, и что, разве за это тебе платят деньги? Конечно нет, тебе платят за качество твоего проекта.
А как именно получен ответ, от реального сервиса или это эмуляция - не важно.
Но есть одно “но”.
Основная проблема в распределенных системах - это синхронизация этих апи.
Очевидно, что апи могут меняться.
А это уже организационный вопрос к менеджеру проекта. Ведь очевидно, что если поменяется внешний апи - надо проводить работы по поддержке этих изменений в вашем проекте. Следовательно, эти изменения должны быть найдены никак не на этапе тестирования (!), а отслежены заранее и в первую очередь о них должен узнавать тот, кто планирует работы, затем команда - разработчики и тестировщики. А затем тебе дают задание на актуализацию автотестов.
А дальше вступает вопрос о стадиях тестирования. Предположим, что в вашей компании несколько компонентов. Конечно же надо проверить их реальную интеграцию в рамках альфа тестирования - это ваша общая заинтересованность как организации. И здесь уже можно подумать и принять решение - эмулируем мы внешний сервис или нет? Дело в том, что внешний сервис не всегда может быть настолько доступен для тестирования, как вам надо. Поэтому юзкейсы могут как подходить под реальную эксплуатацию, так и нет.
Кроме того, внешний сервис живёт своей жизнью и сломаться он может уже на работающей системе, когда все собрано и от тебя это уже никак не зависит.
Вот такой процесс должен быть.
Итого:
Помни, что именно ты тестируешь.
Все, что не важно, можно мокать.
Управлением изменениями должны заниматься менеджеры проекта.
Внешний сервис можно проверить на этапе альфа теста, но это может быть не всегда удобно и возможно.
1 лайк
Чювак выше в целом все правильно говорит на мой взгляд. Однако не стоит забывать, что если мы говорим об автоматизированном тестировании, то скорее всего эти тесты необходимо будет прогонять на CI и закладываться на скорость и стабильность максимального количества тестов.
Если наша система зависит от любой другой внешней системы, то на всех уровнях тестирования, за исключением e2e(или дополнительно интеграционных) тестов нам необходимо отвязать работу нашей системы от внешних систем, таким образом мы будем в первую очередь тестировать непосредственно наш функционал, а уже потом смотреть на то как наш код дружит с “их” кодом.
Однако не всегда есть возможность мокнуть какие- либо зависимости, либо это слишком дорого обойдется. В таких случаях типового решения на мой взгляд нет.
1 лайк
Добавлю пару копеек от себя, пример из моего текущего проекта. Есть у нас один внешний сервис, который до недавних пор был очень нестабильный, но при этом, от него очень много чего зависит. Как таковой я не автоматизировал тестирование этого сервиса. Основное что я сделал - это приготовил запрос для него, который 100 процентов что всегда работает, если сервис работает. И если я вижу, что работа аппликации сломалась из-за этого сервиса, я просто проверяю, сервис вообще работает или нет, используя свой запрос. Если не работает - пишу персоне, которая ответственна за данный сервис. Если работает - вытаскиваю запрос для данной ситуации и начинаем разбираться, что не так. Благодаря это я также смог отыскать у них большую проблему, которую они успешно починили.
Не могу сказать, что это очень полезный ответ на вопрос данной темы, скорее это один из вариантов, что можно сделать, чтобы облегчить немного жизнь.
Какие проблемы могут возникнуть с внешним сервисом:
- Он может перестать отвечать на запросы
- Может изменить контракт(формат отдаваемых данных)
Для первого случая необходимо использовать тесты доступности - просто раз в 3(5, 10) минут проверяйте, что сервис живой и в случае проблем отправляйте письмо(себе, девелоперу)
Для второго случая существуют контракт тесты. Но их написание это чистое программирование
пока если честно - в таких ситуациях грешу на полохой солюшен разработки.
тк значит работа с моками не была задизайнена изначально в приложении (конфиги, проперти и тд)
к сожалению, частый случай
Можно в рамках CI использовать моки
В рамках CDE можно работать с живым сервисом на уровне препода, если конечно у вас не CD
И тесты можно разделать моками или без на уровне билда или с помощью тегов, чтобы избежать дубляжа
Плюс вы должны понимать еще разработка работает с внешними сервисами, может есть что-то похожее на кэширование, тогда можно с соками не парится