Хабрахабр

Как не потерять деньги в черном ящике: методы тестирования биллинга

Проверка платных сервисов — один из ключевых инженерных вопросов в тестировании Badoo. Наше приложение интегрировано с 70 платёжными провайдерами в 250 странах мира, и баг хотя бы в одном из них может привести к непредсказуемым последствиям. 

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

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

В подготовке текста мне помогал мой коллега Виктор Короневич: вместе с ним мы делали доклад на конференции Heisenbug (видео).
Меня зовут Владимир Солодов, я Billing QA Engineer в Badoo: занимаюсь проверкой тестовых интеграций и процессинга платежей. В статье мы расширили область описания на все интеграции с платёжными провайдерами, которые используются в Badoo, подробнее классифицировали и описали практики удаления внешних зависимостей. 

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

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

Поехали!

Специфика тестирования биллинга

Обычно целью бизнеса является получение дохода. В Badoo, социальной сети для знакомств, доход приносят кредиты и премиум-подписки. Кредиты — это внутренняя валюта Badoo. С их помощью, например, можно поднять свой профиль в результатах поиска на первое место, сделать подарок другому пользователю и прочее. Премиум-подписка действует определённый период времени и даёт сразу несколько возможностей: включить режим «невидимки», видеть людей, проявивших к тебе интерес, подтвердить подлинность своего аккаунта и многое другое.  

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

Причины две. Для начала рассмотрим, почему к тестированию платных сервисов необходимо подходить с особым вниманием.

1. Баги в биллинге критичны для бизнеса.

Первая проблема — репутационная. Пользователь, заплативший деньги за сервис, становится более чувствительным (и менее терпимым) к багам в приложении. Любой отзыв в публичном пространстве, будь то обзор приложения в блоге или комментарий в App Store или Google Play, от пользователя, столкнувшегося с багом в платном сервисе, будет более эмоциональным — это фактор, который приводит к репутационным потерям. 

И репутационные потери легко могут превратиться в финансовые.  Вторая проблема заключается в том, что, как только вы начинаете получать деньги от пользователя за сервис, вы становитесь объектом права, защищающего потребителя услуг.

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

Предположим, произошла та же ситуация, только пользователь обратился не в вашу службу поддержки, а в банк, который выдал ему карту, или к платёжному провайдеру. Путь второй — чарджбеки (chargebacks). В этом случае мы имеем дело с чарджбеком. Банк/провайдер инициирует возврат денег. После определённого количества чарджбеков компания получает штраф, а также снижается её рисковый рейтинг. Опасность для бизнеса здесь не только в недополученной прибыли. Снижение рейтинга, в свою очередь, приводит к удорожанию стоимости услуг провайдеров платежей.

В самых запущенных случаях могут иметь место судебные иски (в том числе и коллективные), приводящие к самым серьёзным последствиям. Путь третий — судебные иски (claims). Подробнее об этом можно прочитать здесь.  Так, в 2015 году после судебного иска регулятора Ofgem компания British Gas вынуждена была выплатить многомиллионную компенсацию пользователям, с которых взимала повышенную плату вследствие ошибки в системе начисления оплаты.

2. Для тестирования интеграций нужны знания и экспертиза.

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

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

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

Возможные кейсы биллинга
Рисунок 1.

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

К некритичным можно отнести ошибку нотификации — когда платёжный провайдер информирует о недостатке средств на счёте пользователя, а к критичным — блокировку платёжного метода пользователя. Ошибки могут быть критичными и некритичными. Возможно, пользователь был замечен в мошенничестве и вам стоит более внимательно относиться к его транзакциям.  И если в первом случае вы можете попробовать произвести оплату позже, то во втором — неплохо бы разобраться, почему метод заблокирован.

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

Успешный платёж может быть одноразовым, а может быть подпиской.

Пример расходуемого платежа мы рассмотрели в самом начале статьи — это кредиты в Badoo. Одноразовые платежи (one-off payments) могут быть расходуемыми (consumable) и нерасходуемыми (non-consumable). Предположим, у вас есть персонаж, которым вы играете. Пример нерасходуемого платежа можно привести из игр. В этом случае покупка относится к классу нерасходуемых платежей.  Вы хотите купить для него суперспособности, которые действуют в течение некоторого времени.

Здесь самое большое разнообразие кейсов. Подписки (subscriptions). Помимо первичной покупки подписки, у вас может быть:

  • продление подписки (renew); 
  • закрытие подписки (cancel subscription); 
  • пробная подписка (trial);
  • подписка с грейс-периодом (grace period): когда мы не можем продлить подписку и пытаемся произвести оплату повторно в течение какого-то периода времени, называемого грейс-периодом. Для пользователя грейс-период выглядит так. Предположим, вы купили месячную подписку на газету. Компания, которая присылает вам газеты, пытается списать оплату за следующий месяц подписки по окончании первого месяца, но не может этого сделать (из-за блокировки карты, недостатка средств на счёте и пр.). Если срок действия грейс-периода составляет десять дней, то в течение этого времени компания пытается списать оплату, подписка при этом остаётся действующей. Если у компании не получается списать деньги, подписка аннулируется. Если получается, подписка возобновляется с даты последнего платежа;
  • частичная оплата (partial billing). Например, PayPal позволяет производить частичную оплату, если на счёте пользователя недостаточно средств (partial pay), или разбивать платёж на части (partial invoice). 

Также нужно принимать во внимание две характеристики, которые полностью зависят от платёжного провайдера: подписка может контролироваться вашим приложением или управляться внешне. 

  • Управляемая (internally managed) подписка — это, например, подписка с использованием кредитных карт или PayPal, когда после первой оплаты вам выдаётся токен, с использованием которого вы повторно обращаетесь к провайдеру, при этом не имея платёжных деталей пользователя.
  • Управляемая внешне (externally managed) подписка — это когда платёжный агрегатор полностью берёт на себя управление вашими подписками и просто присылает вам нотификации об их текущих состояниях. 

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

Кейсы биллинга, которые в первую очередь реализуют в системах
Рисунок 2.

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

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

С другой стороны, ситуация осложняется тем, что интеграции с платёжными провайдерами — это всегда взаимодействие с «чёрным ящиком», которое добавляет в процесс тестирования множество переменных.

Технические проблемы в процессе тестирования биллинга

Рассмотрим их на примере интеграции Badoo c App Store. 

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

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

Для начала обратимся к одноразовой расходуемой покупке.

Процесс осуществления одноразового расходуемого платежа
Рисунок 3.

Приложение решает, что должна быть произведена оплата, и на шаге 2 управление передаётся платёжному провайдеру (App Store). На шаге 1 пользователь делает запрос на покупку сервиса. Шаг 4: пользователь предоставляет данные для оплаты. Шаг 3: пользователю предоставляется форма для совершения платежа. Шаг 6: чек, дополненный данными о пользователе, отправляется на сервер для обработки. Шаг 5: провайдер выполняет транзакцию и сообщает о результате приложению, возвращая чек (receipt), содержащий полную информацию о покупке (дата, сервис, статус и прочее). На восьмом шаге уведомление показывается пользователю.  Сервер обрабатывает данные чека и формирует пуш-уведомление для приложения на седьмом шаге.

Таким образом, процесс имеет на самом деле не линейную структуру, как показано на рисунке 2, а ветвящуюся (см. Проблема в том, что шаги 3, 4 и 5 выполняются на стороне платёжного провайдера, практически не контролируются нами и могут иметь различные вариации. 4), и каждая ветка должна быть обработана приложением по-разному. рис.

Ветвление схемы состояний одноразового платежа 
Рисунок 4.

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

Состояния управляемой внешне подписки
Рисунок 5.

Это означает, что пользователь после покупки может управлять ею асинхронно: закрыть, изменить срок действия, запросить возврат средств. Напомню, что подписка Apple, которую мы рассматриваем в качестве примера, является управляемой внешне. Поскольку действие происходит вне нашей системы, на рисунке я обозначил его пунктиром. Мы видим это на шаге 9.

На шаге 10 App Store может изменить статус подписки: продлить, закрыть, ввести в окно грейс-периода.

На этом шаге система отправляет токен, в качестве которого используется чек (receipt), полученный в самом начале при покупке подписки или после её предыдущего продления.  Чтобы мы могли узнать, в каком состоянии находится подписка, есть шаг 11, который специфичен для таких агрегаторов, как App Store и Google Wallet.

Мы получаем чек с актуальным состоянием подписки. Шаг 12 — это ответ провайдера. Результат на этом шаге зависит от асинхронных шагов 9 и 10. 

Получение такой нотификации отображено на шаге 13. Осенью 2018 года Apple для всех реализовала механизм межсерверных (server-to-server) нотификаций, который позволяет уведомлять об изменениях, произошедших с подпиской. В случае с другими провайдерами шаг 13 позволяет исключить из схемы шаги 11 и 12.  Для большинства других провайдеров механизм нотификаций server-to-server является единственным, поэтому можно утверждать, что пример с Apple покрывает всё многообразие кейсов.

На шаге 14 сервер формирует реакцию для приложения на изменение состояния подписки.

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

Полный процесс изменения состояний платежей (на примере управляемой внешне подписки)
Рисунок 6.

Оранжевым цветом окрашены части, которые мы не контролируем в нашей системе, и они являются черными ящиками для нас.

Методы тестирования биллинга

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

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

Реальные платежи 

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

Во-первых, это дорого: очевидно, что для того чтобы совершить реальный платёж, нужно потратить реальные деньги. В остальном реальные платежи плохи. Вы ошибаетесь, если думаете, что в конечном итоге вся сумма вернётся  в компанию: во-первых, провайдеры берут комиссию с каждой транзакции, размер которой, как было описано выше, зависит от рискового рейтинга организации и может достигать 40% (и даже больше); во-вторых, вы можете потерять деньги при тестировании платежей в других странах из-за валютного спреда — разницы между курсами покупки и продажи валюты (покупку вы будете делать по курсу банка на продажу валюты, а возврат придёт по курсу покупки). 

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

Песочницы

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

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

Таблица 1. Соотношение сроков действия реальной подписки и подписки в песочнице Apple

Срок действия подписок в песочнице Google Wallet, принятый по умолчанию, приведён в таблице 2, и он может настраиваться в консоли продавца.

Таблица 2. Настройка срока действия подписки в песочнице Google

д., используя соотношение из таблицы 3. В отличие от песочницы Apple, в песочнице Google можно также проверить триал, грейс-период и т.

Таблица 3. Срок действия дополнительных функций подписки в песочнице Google

Закрытие подписки тоже может быть реализовано по-разному: в песочнице App Store закрытие выполняется после пятого продления, а в Google Wallet оно выполняется из консоли продавца или на девайсе из Play Store.

Наш опыт показывает, что из более чем 70 платёжных провайдеров, которые интегрированы в Badoo, только две песочницы могут похвастаться полной функциональностью и стабильной работой. Проблема песочниц в том, что провайдеры по-разному относятся к их качеству. Остальные провайдеры имеют либо стабильные, но урезанные в плане функциональности песочницы (как Google Wallet), либо нестабильные и сильно урезанные в функциональности (как App Store и Fortumo). Это песочницы Adyen и PayPal. А есть провайдеры, которые вообще не имеют и не собираются иметь песочницу.

Классификация песочниц по стабильности и функциональности 
Рисунок 7.

Устранение внешних зависимостей

Если мы убедили вас в том, что тестирование с использованием реальных платежей — это дорого и неэффективно, а платёжные провайдеры не предоставляют песочницы должного качества, то остаётся обратиться к различным способам устранения внешних зависимостей. Их всего три: моки, фейки и стабы.

рис. Моки в биллинге — это формирование реакций вашей системы на запросы с заранее определёнными параметрами без реального обращения к платёжному провайдеру (см. Например, запрос к провайдеру СМС-платежей на номер +7111-111-11-11 перехватывается на этапе отправки запроса к провайдеру и формирует реакцию системы в виде успешного платежа. 8). Запрос на номер +7111-111-11-12 также перехватывается, но приводит к реакции на ошибку с кодом «Не хватает средств для проведения транзакции».

Схема мока
Рисунок 8.

рис. Фейки в биллинге — это подделки нотификаций (как будто они приходят от реального провайдера) (см. Интеграция с каждым провайдером предполагает ограниченный набор реакций системы на ограниченный набор типов нотификаций или реситов. 9). На основе этой информации для каждого отдельного платежа можно сформировать набор нотификаций (с подписями и прочими фейковыми атрибутами безопасности), которые наша система будет считать реальными нотификациями от платёжного провайдера.

Схема фейка
Рисунок 9.

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

Схема стаба
Рисунок 10.

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

Шаги 3, 4, 5 являются ключевыми для интеграции: передача управления платёжному провайдеру, отправка запроса провайдеру и получение ответа. Вернёмся к процессу осуществления одноразового платежа. Остальные шаги при этом «выносятся за скобки». При использовании каждого из рассматриваемых способов устранения внешних зависимостей фокус направлен на какие-то из этих шагов: при использовании мока мы моделируем передачу управления и отправку запроса, при использовании стаба — только передачу управления, при использовании фейка — получение ответа.

Моделирование взаимодействия приложения с провайдером при разных методах устранения внешней зависимости (на примере одноразовой покупки в App Store)
Рисунок 11.

С другой — моделирование каждого шага делает метод дороже, поскольку требует изменений в системе. С одной стороны, такое устранение шагов приводит к рискам (например, можно пропустить баг в нетестируемых шагах). Например, моки и фейки, когда при отправке запроса на определённый номер не формируется реакция системы, а отправляется фейковая нотификация на точку входа для нотификаций на нашем сервере. Поэтому на практике мы используем комбинации методов. Естественно, подобные реализации должны быть ограничены окружениями для разработчиков и не должны попадать на прод.   Или стабы и фейки, когда при выборе реакции из стаба также отправляется фейковая нотификация.

Ограничения методов тестирования биллинга

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

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

Результаты оценки мы свели в таблицу.

Сравнительная характеристика методов тестирования биллинга
Таблица 4.

Годовую подписку нужно тестировать год. Реальный платёж. Довольно ограниченное количество кейсов. Он довольно дорогой: мы постоянно тратим реальные деньги, оплачивая транзакции провайдерам. Но зато это единственный метод, который позволяет тестировать весь процесс интеграции.

Поэтому ими можно покрыть разное количество кейсов (и точно не все). Песочница. Песочницы, например, у Apple и Google, отличаются. Однако это, пожалуй, самый дешёвый метод.  Песочница не предоставляет возможности полноценного end-to-end тестирования: даже код в самой песочнице может отличаться от кода на проде.

Мы можем покрыть весь набор кейсов. Фейки, моки, стабы — самый гибкий метод. Метод недёшев: нужно писать код и поддерживать его в актуальном состоянии. В силу специфики этого метода мы не тестируем весь процесс платежа целиком.

Выбор метода тестирования 

Для того чтобы определить, какой из методов на каком этапе использовать, обратимся к классической пирамиде тестирования. 

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

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

Если мы соотнесём это с критериями оценки методов тестирования, то получим такое соотношение: для тестов внизу пирамиды — фейки, моки, стабы; для тестов вверху пирамиды — ориентированные на интеграцию методы: реальный платёж и песочница. 

Соотношение этапов и методов тестирования на пирамиде тестирования  
Рисунок 12.

Антипаттерны при выборе метода

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

Давайте рассмотрим примеры трёх антипаттернов тестирования, не соответствующих соотношению на рисунке 12, с которыми мы столкнулись в Badoo.

Реальные платежи внизу пирамиды 

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

Вывод такой: не нужно использовать реальные платежи везде.
 

Песочницы внизу и наверху пирамиды

Первая проблема, возникающая при избыточной зависимости от песочниц, — это сбои в их работе. Например, для тестирования платежей Apple песочница долгое время оставалась единственным способом. В итоге мы столкнулись с последствиями её нестабильной работы. Было два случая, когда песочница не работала вообще. Она не работала в течение двух недель: в итоге четыре релиза клиентского приложения мы вынуждены были выпускать без какого-то адекватного тестирования. 

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

Для одного из пользователей ресит достиг 1 Гб — естественно, тестовый стенд просто не выдержал передачи такого объёма данных. Последствия использования песочниц внизу пирамиды — появление различных инфраструктурных проблем: при использовании одного и того же аккаунта в песочнице для большого количества платежей размер передаваемого ресита или нотификации может возрастать, потому что Apple накапливает историю покупок.

Устранение внешних зависимостей наверху пирамиды

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

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

Выводы

  1. Платные сервисы должны тестироваться особенно тщательно, поскольку даже самые незначительные баги могут привести к неожиданным последствиям. 
  2. При реализации интеграции с платёжным провайдером (особенно при использовании итеративных методологий разработки) важно изучить и составить карту всех возможных состояний провайдера. Итеративность может быть использована в усложнении реакции системы на определённые состояния, но сами состояния система должна классифицировать правильно с самого начала. 
  3. Платёжный провайдер всегда является «чёрным ящиком» для нас, тестировать его работу очень сложно. Не стоит пытаться использовать какой-то один метод и тестировать с его помощью всё — это приведёт к печальным последствиям. Лучше протестировать всё в сочетании, в композиции: фейками, моками и стабами — все кейсы, песочницей и реальным платежом — пару кейсов для проверки интеграции. 
  4. При использовании фейков, моков и стабов важно помнить, что это модели реального платежа, и, как любая модель, они имеют степень приближения к реальности и риски. Эти риски должны быть оценены и покрыты либо реальными платежами, либо дополнительными проверками.

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

Всем большой прибыли и меньше багов!  Спасибо за внимание!

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть