Java commons-httpclient: проверка значений времени ожидания

Аннотация: как разработчики определяют тайм-аут Integration 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. Похоже, что тайм-ауты SO должны быть установлены ниже (поскольку они просто измеряют расстояние между байтами в пути), а тайм-аут соединения — это то, что мы изначально планировали использовать (т.е. начальная задержка между запросом и возвращенным 1-м байтом). Вот код, который мы собрали и планируем использовать:

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

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

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

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


java integration-testing apache-commons-httpclient
person Chad Van De Hey    schedule 02.04.2019    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

person java-addict301    schedule 02.04.2019
comment
У вас есть пример возможности jmeter, о которой вы упомянули? - person Chad Van De Hey; 02.04.2019
comment
Эй, конечно, я делаю. Я пошел дальше и добавил его в свой ответ (ответ SO, показывающий это). - person java-addict301; 03.04.2019

arrow_upward
0
arrow_downward

Выбрав маршрут с фиктивным сервером, мне удалось настроить небольшой веб-сервер с конечной точкой 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. Это немного хакерски, но оно работает, чтобы проверить функциональность так, как я хотел (просто, легко и эффективно).

person Chad Van De Hey    schedule 04.04.2019