Whats the benefit or purpose of unit testing a void method like doFilter?

Question

I am on the java tomcat stack and creating a new filter. https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpFilter.html I am interested in unit testing it because I want to have 100% branch coverage.

This filter wraps the response object. We override the default behavior of the response such that whenever we call response.addCookie(cookie), we append the string "happy" to the cookie name:

HappyCookieFilter implements Filter {
HappyCookieResponseWrapper happyCookieResponseWrapper;
...

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

...
}

1. Assuming the HappyCookieResponseWrapper is already unit tested, what would be the benefit of testing doFilter method?
2. How would I test the HappyCookieFilter.doFilter and what should I assert?

Answer 1

"What would be the benefit of testing doFilter method?"

None!

Quoting answer to the question " Should unit tests be written for getter and setters? ":

Unit tests are there to test the behaviour of your code, ...

There is really no behavior to be tested in that Filter code. The behavior to be tested is in the HappyCookieResponseWrapper class, and you're already testing that. Repeating that test would just be a waste of time.

---

"I want to have 100% branch coverage"

Quoting a different part of the same answer above:

@Will said you should aim for 100% code coverage, but in my opinion that's a dangerous distraction. You can write unit tests that have 100% coverage, and yet test absolutely nothing.

Answer 2

If the doFilter() method has 'interesting' logic like special filtering or routing rules, testing them whould be the purpose of testing this void method. Generally speaking, if a void method has logic to create side effecs (apart from just calling chain.doFilter() in your case) then the purpose of testing said void method would be to test that logic. On the other hand this logic could and should live in a non-void method (maybe in another class) that could be tested on it's own.

Having 100% coverage (line or branch) is nothing to aim for (especially if you don't make sure that the code isn't only covered but also asserted).

Answer 3

It is a perfectly valid class and method to unit test.

Test in chain.doFilter whether (the intended behavior of happyCookieResponseWrapper.wrap(response) was passed as request. No technicalities. Maybe that a cookie was set in the request or so. The business logic and functioning of happyCookieResponseWrapper need not be repeated. There might be an elementary overlap (cookie was set), but that happens at two different levels.

By the way I am a bit surprised seeing a response wrapper for a request, but as it compiles it'll be alright.

It is a very narrow/trivial check. But assume this code at some time in the future is redesigned to use an other wrapper class, that does not fulfill the correct behavior. The regression error will then be found fast, as opposed to hearing from a fuzzily described error and processing a ticket.