Запуск тестов против API Recurly вместе с живым сайтом

Question

У меня есть небольшая проблема. Я пытаюсь разработать против API Recurly, но я не могу найти способ использовать тестовые учетные записи или тестовый шлюз вместе с живой и запущенной учетной записью Recurly.

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

Answer 1

Обычно мы рекомендуем создать второй сайт, предназначенный только для разработки и тестирования. Затем, поскольку @atif предложил вам использовать отдельный ключ API для тестов и разработки, не беспокоясь о влиянии на ваш производственный сайт. Один недостаток этого подхода - вам нужно будет воссоздать любые планы и купоны, которые вы используете в своем тестировании.

Возможно, вам понадобятся разные уровни тестирования. Вам понадобятся несколько тестов, которые фактически интегрируются с нашими серверами, создают учетные записи, подписываются и т. Д., Которые вы запускаете нечасто, потому что они будут медленнее. Для большинства ваших тестов я попытаюсь следовать советам @ ryan1234 и использовать stub/mock/fixtures для удаленных запросов. Это сделает намного более быстрые тесты.

Answer 2

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

Answer 3

Я бы создал интерфейс между вашим кодом и вызовами Recurly API.

Поэтому логика будет идти:

код приложения -> Интерфейс -> Recurly API вызова.

Затем шаги к испытанию будет что-то вроде этого:

1. сделать один или два безопасных вызовов в режиме реального HTTP на Recurly.
2. Запишите запрос HTTP-запроса (1) в файл/строку.
3. Замените живую реализацию вашего интерфейса фиктивным интерфейсом.
4. Имейте фиктивный интерфейс, чтобы сравнить данные из (2) с данными, сгенерированными при запуске теста.
5. Если данные через фиктивный интерфейс соответствуют тому, что вы ожидаете, тогда вы хороши!

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

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