- PVSM.RU - https://www.pvsm.ru -
Современные приложения редко работают в изоляции, чаще всего они интегрируются с множеством сторонних сервисов. Поэтому остро встает вопрос тестирования этой интеграции в рамках интеграционного или функционального тестирования. И тут можно наступить на многие грабли, о которых я и собираюсь поговорить. Для кого эта тема актуальна, прошу под кат.
Первое решение, которое приходит в голову — тестировать напрямую на реальном сервисе. В некоторых случаях это может быть обосновано, но часто приводит к следующим проблемам:
Описанные проблемы заставляют вас искать альтернативные решения и они существуют.
На помощь вам могут придти разнообразные варианты заглушек (не нашел лучшего перевода термина mock objects). Есть несколько вариантов заглушек: mock, stub, dummy, spy, fake. Знать и различать их нужно и важно, поэтому стоит почитать [1] и разобраться в специфике, но речь пойдет не об этом. Нам понадобится только один из видов заглушек, который наиболее подходит для работы с внешними сервисами — fake реализация.
Fake реализация представляет из себя упрощенный вариант настоящего сервиса, который работает полностью предсказуемо, локально, дает полный доступ к данным и настройкам, а также не требует никакой дополнительной работы в каждом тесте. Таким образом, мы сможем прозрачно заменить настоящий сервис в тестах на fake реализацию и решить все проблемы. Звучит просто? Не очень!
Во-первых, нам нужно будет реализовать этот упрощенный вариант сервиса, на что понадобится время и усилия разработчиков. Вы счастливчик, если ваш внешний сервис предоставляет fake реализацию для локального тестирования. Тогда вы просто скачиваете библиотеку, настраиваете, запускаете и пользуетесь на здоровье. Некоторые сервисы позволяют получить доступ к специальной версии внешнего сервиса для тестирования, которая не подвержена перечисленным в первой части проблемам. Но таких сервисов единицы. Почти всегда вам придется писать fake реализацию самостоятельно.
Во-вторых, вам придется позаботиться о том, чтобы ваша fake реализация ведет себя так же как реальный сервис. Это одни из самых частых граблей, на которые наступают сторонники описанного подхода. Вы делаете fake реализацию сегодня, а через неделю реальный сервис начинает вести себя по-другому. Ваши тесты по-прежнему проходят и вы спокойно живете пока не задеплоите ваш код на «живые» сервера. И вот там вас ждет неприятный сюрприз!
Эту проблему очень легко исправить, но придется приложить еще немного усилий. Вам нужно написать еще один набор тестов, теперь уже на реальный сервис, целью которого будет контроль и поддержание надежности протокола между вашим приложением и сторонним сервисом. Это некоторый вариант smoke тестов на внешний сервис, которые можно запускать раз в час, день или неделю в зависимости от стабильности вашего внешнего сервиса. Тогда вы действительно контролируете и тестируете интеграцию с внешним сервисом и избегаете сюрпризов при его изменении.
Описанное решение подходит не всем (в принципе как и любое другое). Поэтому я дам несколько советов, с помощью которых вы можете немного сгладить проблемы из первой части этой статьи.
Кому-то даже этот набор мер позволит существенно улучшить свое тестирование.
А вообще, самое главное — это понимать описанные проблемы и иметь желание их разрешить. Тогда можно придумать множество альтернативных решений и подходов, которые будут работать еще лучше приведенных в статье для вашего конкретного случая. И тогда ваши тесты снова будут быстрыми, надежными и еще более полезными для вашей команды.
Автор: xpinjection
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/27999
Ссылки в тексте:
[1] почитать: http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html
[2] fake-s3: https://github.com/jubos/fake-s3
[3] Источник: http://habrahabr.ru/post/170637/
Нажмите здесь для печати.