Как безопасно протестировать код, требующий внешнего веб-интерфейса API

Question

Я собираюсь отправиться в путешествие по написанию библиотеки java для переноса веб-API, и я бы хотел написать тесты на этом пути, чтобы убедиться, что все персиковый. Я использую JUnit довольно долгое время, и мне очень удобно использовать его вместе с такими инструментами, как PowerMockito/Mockito. Однако я обеспокоен тем, что тесты могут завершиться неудачно, если API не работает, или я не могу его достичь, поскольку в конечном итоге планирую запустить его на сервере CI (travis-ci) и хотел бы, чтобы процедура сборки-тестирования-развертывания была такой же насколько это возможно.

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

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

TestUtil.java

public static boolean isReachable() { 
    try (Socket socket = new Socket("api.host.com", 80)) { 
     return true; 
    } catch (Exception e) { 
     return false; 
    } 
} 

TestCase.java

@BeforeClass 
public static void testReachable() { 
    Assume.assumeTrue("API was not reachable, test cannot run", TestUtil.isReachable()); 
} 

Я принимаю его с @BeforeClass просто из паранойи.

Однако это не связано с ошибками HTTP, только проверка того, что что-то прослушивает порт 80. Стоит ли заменять запрос HEAD? Кроме проверки ошибок, я честно не уверен. Я не хочу использовать HTTP без подтверждения, это лучший способ, поскольку эта библиотека может стать довольно большой.

Edit: Я просто наткнулся на InetAddress#isReachable(), хотя согласно статье я читал это не самый надежный.

Answer 1

Вы должны провести различие между модульными тестами и интеграционными тестами.

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

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

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

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

Это будет другая история, когда у вас будет сложный ландшафт услуг с большим количеством сопоставлений, конфигурации и маршрутизации compex. Тогда ваши интеграционные тесты - лучший способ проверить, что все ваши услуги подключены и правильно разговаривают друг с другом. Я бы назвал эти тесты «черного ящика», где вы указываете тесты с точки зрения ожидаемой функциональности системы в целом (например, истории пользователей), независимо от деталей реализации.

Answer 2

В зависимости от размера API и того, что вы намерены делать с ним, код (как вы сказали сами) может стать довольно большим. Прежде чем отправиться в путешествие, возможно, вы могли бы оценить то, что уже существует, чтобы сделать это, как RetroFit.

Следует также упомянуть, что RetroFit по характеру того, что он говорит, с внешними API. Он также имеет tests and is open source. Вы можете посмотреть их тесты на вдохновение.