Size: a a a

2021 May 12

ГР

Геннадий Романов... in pro.jvm
Всем привет, метод отправляет файл на сервер (java) что мокать при ЮНИТ тестировании?
Server или сущность которая внутри метода делает отправку?
источник

EF

Eugene Freeman in pro.jvm
rtb
источник

ch

central hardware in pro.jvm
Это видимо уже интеграционный тест так что ничего не мокать
источник

ГР

Геннадий Романов... in pro.jvm
тест пишу как раз ЮНИТ возник спор с коллегой что мокать
источник

ГР

Геннадий Романов... in pro.jvm
да и что собственно тетсировать
источник

I

Ivan in pro.jvm
Ответ мокать
источник

DC

Denis Chikanov in pro.jvm
А как ты пишешь юнит-тест, если ещё не определился, что тестируешь, лол?
источник

ГР

Геннадий Романов... in pro.jvm
так вот я и спрашиваю что нужно в Юнит тестировать в методе,
который отправляет запрос на сервер и обрабатывает ответ?
источник

DC

Denis Chikanov in pro.jvm
Первый вопрос был совсем не такой, во-первых. :)
Во-вторых, отправка запроса и обработка ответа, вообще говоря, две разные вещи, которые друг от друга не очень зависят, и если хочется, то надо тестировать их отдельно
источник

E

Etki in pro.jvm
Тут проблема не с optional, а в целом с менеджед-языком, у которого сложнопредсказуемая латенси

Вообще джит должен очень прилично все заинлайнить и не должно быть особых проблем.
Там ещё скаляризация есть, но я буду опять ржать если начну про нее.
источник

ГР

Геннадий Романов... in pro.jvm
ну так можно каждую строчку в методе отдельно тетировать
источник

DC

Denis Chikanov in pro.jvm
Ну ты спросил "что тестировать", я ответил. Не хочется что-то тестировать - не тестируй, всё просто, ну.
источник

ГР

Геннадий Романов... in pro.jvm
нет просто в чем тогда смысл юнит тестирования если мы начинаем разбивать тестируемый метод на под методы
источник

ГР

Геннадий Романов... in pro.jvm
переписывать метод на два метода для того чтобы их отдельно тестировать похоже на бред
источник

DC

Denis Chikanov in pro.jvm
Смысл в том, чтобы у тебя у единицы кода не было нескольких независимых ответственностей.
источник

ГР

Геннадий Романов... in pro.jvm
CloseableHttpClient client = HttpClients.createDefault();

HttpPost httpPost = new HttpPost(urlSend);
HttpEntity httpEntity = EntityBuilder.
create()
       .setContentType(ContentType.
create("text/csv", StandardCharsets.UTF_8))
       .setFile(fileCsv)
       .build();
httpPost.setEntity(httpEntity);
httpPost.addHeader("Authorization", "Basic " + token);
httpPost.addHeader("Accept", "application/xml");

try (CloseableHttpResponse response = client.execute(httpPost))

...
Если мокать ответ т.е нужно создать мок Mockit  mockClient =  EntityBuilder.create()
и от него создать мок then(mockClient.execute(httpPost)... это будет работать?

и надо будет продублировать по факту создание httpPost?
источник

VP

Vladimir Petrakovich in pro.jvm
Это называется "рефакторинг"
источник

ГР

Геннадий Романов... in pro.jvm
а кто сказал что два метода лучше чем один?
источник

VP

Vladimir Petrakovich in pro.jvm
Если их так будет проще тестировать, и меньше смешиваются разные операции (а это вроде тот случай), то много кто говорит (включая КО), что так лучше
источник

DC

Denis Chikanov in pro.jvm
У тебя есть две независимые ответственности
Ты можешь тестировать их отдельно, а не внезапно узнать, что у тебя респонс сломался из-за того, что у сервера поменялся апи, а структуру твоего запроса перестали поддерживать
источник