Java commons-httpclient: тестирование значений тайм-аута - PullRequest
Новая
       51

Java commons-httpclient: тестирование значений тайм-аута

1 голос
/ 02 апреля 2019

Аннотация : как разработчики TEST интеграции таймауты для запросов http?

Предыстория : У моей команды есть проблемы, связанные с необычно продолжительными HTTP-запросами. Мы используем commons-httpclient версию 3 от Apache. Код выглядит примерно так: 

PostMethod post = new PostMethod(endpoint);
post.getParams().setSoTimeout(someInt);
httpClient.executeMethod(post);

Время для выполнения этого запроса обычно приемлемо (2 секунды или около того), но иногда мы видим 50-60 секундные запросы, несмотря на то, что наш тайм-аут SO установлен на 4 секунды. Это побудило меня провести некоторое исследование и обнаружило, что большинство людей устанавливают тайм-ауты подключения ANNNNND ТАК. Похоже, что тайм-ауты SO должны быть установлены ниже (так как они просто измеряют расстояние между байтами в пути), и тайм-аут соединения - это то, что мы изначально планировали использовать (т.е. первоначальная задержка между запросом и возвращением 1-го байта). Вот код, который мы использовали и планируем использовать: 

httpClient.getHttpConnectionManager().getParams()
                  .setConnectionTimeout(someInt);

httpClient.getHttpConnectionManager().getParams()
                  .setSoTimeout(someInt);

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

Причина, по которой я обращаюсь к Stack Overflow, состоит в том, чтобы посмотреть, как другие тестируют это / не тестируют это. Я хочу избежать тестирования этой функциональности в среде производительности любой ценой. Еще одной моей мыслью было настроить mockserver для ответа httpclient с программируемой задержкой. Я еще не видел такого примера.

Ответы [ 2 ]

1 голос
/ 02 апреля 2019

Прежде всего, нет такого понятия, как модульное тестирование http-запросов - это было бы интеграционное тестирование.

Во-вторых, вы можете использовать такой инструмент, как JMeter, для отправки http-запросов и проверки получения ответа через определенное время , как показано здесь в JMeter .

0 голосов
/ 05 апреля 2019

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

Настройка облегченного сервера: 

TJWSEmbeddedJaxrsServer server = new TJWSEmbeddedJaxrsServer();
server.setPort(SERVER_PORT);
server.getDeployment().getResources().add(new TestResource());
server.start();

Конечная точка API: 

/**
 * In order to test the timeout, the resource will be injected into an embedded server.
 * Each endpoint should have a unique use case.
 */
@Path("tests")
public class TestResource {

    @POST
    @Produces({MediaType.APPLICATION_XML})
    @Path("socket-timeout")
    public Response testSocketTimeout() throws InterruptedException {
        Thread.sleep(SOCKET_TIMEOUT_SLEEP);
        return Response.ok().build();
    }
}

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

...