Как проверить API стиля перенаправления

1

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

Немного контекста:

Основная идея состоит в том, чтобы интегрироваться с платежной системой аналогично этой демонстрации.

Основной поток - это что-то вроде:

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

Моя основная проблема заключается в том, как я могу подойти к автоматическому тестированию интеграции для этого типа сценариев? Основные идеи, которые у меня есть:

  • Используйте stubbing или mocking для ссылки на транзакцию и ответа. Но это больше соответствует единичному тестированию, чем интеграционное тестирование. Я не против этого, но сначала хотел бы изучить интеграционные тесты.
  • Возможно, я должен попробовать какое-то автоматическое заполнение формы. Поэтому я бы сделал запрос типа curl на URL-адрес перенаправления и запрос на запрос типа curl после проверки того, что делает веб-сайт перенаправления.
  • Используйте какой-то инструмент для веб-тестирования, например, селен или что-то в этом роде.
Теги:
unit-testing
web-services
automated-tests
tdd

1 ответ

3

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

(Я исхожу из предположения, что вы не хотите использовать производственную версию службы платежей при выполнении своих тестов)

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

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

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

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

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

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

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

  • Для моего сквозного набора тестов (т.е. того, который развертывает тестовую версию системы и проверяет ее до конца), я бы создал фальшивую версию службы платежей, которая может быть развернута с помощью тестовой системы, и использовать ее для тестирования. Это позволяет полностью протестировать вашу систему полностью и до конца, а также с конечной точкой стабильного платежа. Эти сквозные тесты должны включать сценарии, в которых служба не может быть найдена, сообщает об ошибке, что-то вроде этого. Учитывая это сквозное тестирование, такой инструмент, как Selenium, подходит для тестов, управляемых через веб-интерфейс.

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

  • 2
    Если вы пишете тестовый набор услуг, предоставляемых поставщиком, я всегда рекомендовал бы сначала обернуть сервис поставщика (чтобы предложить только те функции, которые действительно необходимы вашему приложению) и протестировать его. Дж. Б. Рейнсбергер называет это «контрактными испытаниями»

Ещё вопросы

Сообщество Overcoder
Наверх
Меню