Как издеваться над новым экземпляром RestTemplate?

Я пишу модульный тест для моего устаревшего кода, который выглядит примерно так:

public class SomeClass {
public SomeResponse logToServer() {
    SomeResponse response = null;
    try{ 
        RestTemplate restTemplate = new RestTemplate();
        SomeRequestBean request = new SomeRequestBean();
        response = restTemplate.postForEntity("http://someUrl", request, SomeResponse.class);
        System.out.println(response.toString());
    } catch(Exception e) {
        e.printStackTrace();
    } 
    return response;
}

}

Я знаю, что могу переместить RestTemplate выше и аннотировать его как @AutoWire и объявить его как класс bean-компонента или использовать power mockito, чтобы имитировать создание нового экземпляра. Но я не хочу менять этот устаревший код и любой ценой избегаю использования мощного Mockito, потому что только для одного теста я не хочу добавлять совершенно новую зависимость к моему pom.xml. Так что просто интересно, есть ли способ, с помощью которого я могу издеваться над этим restTemplate?


java junit resttemplate mockito powermockito
person James    schedule 27.11.2019    source источник
comment
Это не ваш настоящий код, он не скомпилируется в объявлении класса. Пожалуйста, покажите что-нибудь компилируемое, так что жутко придется догадываться, что куда идет (код класса или метода).   -  person daniu    schedule 27.11.2019
comment
Я отредактировал код. Однако я не могу поделиться точным кодом уровня предприятия. но это выглядит примерно так, как описано выше.   -  person James    schedule 27.11.2019
comment
@James, основываясь на заявленных ограничениях, я бы сказал нет, скорее всего, нет другого способа издеваться над restTemplate. Предметный код тесно связан с проблемами реализации, что затрудняет его изолированное тестирование без внешних зависимостей/инструментов.   -  person Nkosi    schedule 27.11.2019

Ответы (1)


arrow_upward
1
arrow_downward

Чтобы ответить на ваш вопрос, нет ограничений, которые вы опубликовали, нет возможности издеваться над RestTemplate и модульным тестом.

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

Что касается мощности mock и power mockito. Хотя я согласен с тем, что этих инструментов следует избегать, но не по той причине, которую вы опубликовали. Обратите внимание, что эта зависимость относится к сфере тестирования, она в любом случае не достигнет рабочей среды даже для устаревших сред. Итак, если приоритет состоит в том, чтобы не изменять устаревший код, то внедрение PowerMock — это «наименьшее зло».

Однако, если мы говорим конкретно о шаблоне rest, вы можете воспользоваться некоторыми фактами о шаблоне spring rest, которые в любом случае можно использовать для его тестирования.

Вариант 1

Первый метод (если позволяет среда) использует аннотацию @RestClientTest. Это позволит указать тестируемую службу и предоставит фиктивную реализацию чего-то под названием MockRestServiceServer, которое будет представлять сервер, к которому вы пытаетесь подключиться в фиктивной среде. Затем вы сможете указать ожидания от этого сервера, и, надеюсь, код будет работать. Внимание: это не модульный тест — это интеграционный тест, который запускает контекст Spring, поэтому он будет намного тяжелее/медленнее, чем обычный модульный тест.

Здесь вы можете найти рабочий пример этого подхода, ознакомьтесь с этой статьей. содержит и другие техники.

Вариант 2

Идея, лежащая в основе второго метода, заключается в том, что RestTemplate на самом деле является оболочкой над клиентскими библиотеками, она сама по себе не осуществляет HTTP-взаимодействия.

Его можно настроить для работы с HttpClient apache, OkHttpClient, по умолчанию он работает с URLConnection, открывающим соединение для каждого запроса. Таким образом, вы можете создать тест, который настроит оставшийся клиент для работы с каким-то конкретным движком, который вас интересует/по вашему выбору, а затем проверить, как тестировать код, который использует этот движок напрямую. Решения будут разными в зависимости от фактического движка, используемого в проекте.

person Mark Bramnik    schedule 27.11.2019