java.net.SocketTimeoutException в интеграционном тесте на Java при использовании Wiremock с использованием Spring Boot с Junit - PullRequest
0 голосов
/ 27 февраля 2019

Я использую Wiremock для проверки ответа внешнего оператора в интеграционном тесте:

@ClassRule
public static WireMockClassRule zainWireMockStatic = new WireMockClassRule(9900);

и получаю это исключение

requesting to java.net.SocketTimeoutException: connect timed out timed out

Это мой Wiremock

 private static void wireMockZainUnSubscriptionRequest() {
        zainWireMockStatic.stubFor(get(urlPathMatching("/api/unsubscribe")).willReturn(
                aResponse().withStatus(200).withHeader("Content-Type", "application/json")
                        .withBody(FileUtils.readFileFromClasspath(
                                "data/mocks/zain_unsubscribe_success_response.json"))));

    }

и это мой тест

    @Test
    public void unsubscribeUserWithSuccessResponse() {
        wireMockZainUnSubscriptionRequest();
        given().body(FileUtils.readFileFromClasspath("data/message/unsubscribe_request.json"))
                .contentType(ContentType.JSON).post(UNSUBSCRIBE_API).then().statusCode(200)
                .body("user_id", equalTo(USER_ID));

    }

1 Ответ

0 голосов
/ 27 февраля 2019

Проблема в том, что Spring Boot runner запускает и останавливает свой контейнер сервлета один раз для класса .Если вы используете правило WireMock, оно запускается и останавливается один раз для метода тестирования .Это означает, что пулы соединений в приложении Spring становятся недопустимыми между тестовыми наборами.

У вас есть три варианта исправить это:

  1. Переключиться на интеграцию WireMock команды Spring: http://cloud.spring.io/spring-cloud-static/spring-cloud-contract/1.1.2.RELEASE/#_spring_cloud_contract_wiremock
  2. Переключитесь на использование @ClassRule, чтобы WireMock запускался и останавливался для каждого тестового класса.
  3. Сконфигурируйте ваш HTTP-клиент Spring для обнаружения и отбрасывания мертвых подключений в пуле.Преимущество этого варианта в том, что ваше приложение будет более устойчивым к отказам в производственной системе, так как многие балансировщики нагрузки / обратные прокси / плавающие IP-адреса будут демонстрировать аналогичное поведение.
...