В чем выгода или цель модульного тестирования пустого метода, такого как doFilter?

Question

Я в стеке java Tomcat и создаю новый фильтр. https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpFilter.html Я заинтересован в модульном тестировании, потому что хочу иметь 100% охват ветвей.

Этот фильтр оборачивает объект ответа. Мы переопределяем поведение ответа по умолчанию так, что всякий раз, когда мы вызываем response.addCook ie (cook ie), мы добавляем строку «happy» к имени cook ie:

HappyCookieFilter implements Filter {
HappyCookieResponseWrapper happyCookieResponseWrapper;
...

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) {
    chain.doFilter(req, happyCookieResponseWrapper.wrap(res));
}

...
}

1. Если предположить, что HappyCookieResponseWrapper уже подвергнут модульному тестированию, какая польза от тестирования метода doFilter?
2. Как мне проверить HappyCookieFilter.doFilter и что я должен утверждать?

Answer 1

"Какая польза от тестирования doFilter метода?"

Нет!

Цитировать ответ на вопрос " Должны ли проводиться юнит-тесты? написано для геттеров и сеттеров?":

Существуют юнит-тесты для проверки поведения вашего кода, ...

В этом коде Filter поведение не проверяется. Поведение, которое нужно протестировать, относится к классу HappyCookieResponseWrapper, и вы уже тестируете это. Повторение этого теста будет пустой тратой времени.

---

«Я хочу получить 100% покрытие филиала»

Цитирование другой части того же ответа выше:

@ Уилл сказал, что вы должны стремиться к 100% охвату кода, но, на мой взгляд, это опасное отвлечение. Вы можете написать модульные тесты, которые имеют 100% покрытие, но при этом абсолютно ничего не тестируют.

Answer 2

Это вполне допустимый класс и метод для модульного теста.

Проверка в chain.doFilter, было ли (предполагаемое поведение happyCookieResponseWrapper.wrap(response) передано как запрос. Никаких технических подробностей. Возможно, что повар ie был установлен в запросе или около того. Бизнес-логика c и функционирование happyCookieResponseWrapper не должны повторяться. Может быть элементарное перекрытие (был установлен cook ie), но это происходит на двух разных уровнях.

Кстати, я немного удивлен, увидев упаковщик ответа на запрос, но когда он будет скомпилирован, все будет в порядке.

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

Answer 3

Если метод doFilter() имеет «интересные» логики c, такие как специальные правила фильтрации или маршрутизации, то их тестирование может стать целью тестирования этого пустого метода. Вообще говоря, если метод void имеет logi c для создания побочных эффектов (кроме простого вызова chain.doFilter() в вашем случае), то целью тестирования указанного void-метода будет тестирование этого logi c. С другой стороны, эта логика c может и должна существовать в не пустом методе (может быть, в другом классе), который можно протестировать самостоятельно.

Наличие 100% покрытия (линии или ветви) - ничто стремиться к (особенно если вы не уверены, что код не только покрыт, но и утвержден).