单元测试像 doFilter 这样的 void 方法的好处或目的是什么？

Question

我在 java tomcat 堆栈上并创建了一个新的过滤器。 https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpFilter.html我对单元测试很感兴趣，因为我想要 100% 的分支覆盖率。

此过滤器包装响应对象。 我们覆盖响应的默认行为，这样每当我们调用 response.addCookie(cookie) 时，我们都会将字符串“happy”附加到 cookie 名称：

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方法有什么好处？”

没有任何！

引用问题“是否应该为 getter 和 setter 编写单元测试？ ”的答案：

单元测试用于测试代码的行为，...

在那个Filter代码中确实没有要测试的行为。 要测试的行为在HappyCookieResponseWrapper类中，您已经在测试它。 重复那个测试只会浪费时间。

---

“我想要 100% 的分支机构覆盖率”

引用上面相同答案的不同部分：

@Will 说你应该瞄准 100% 的代码覆盖率，但在我看来，这是一种危险的分心。 您可以编写具有 100% 覆盖率的单元测试，但绝对不进行任何测试。

Answer 2

如果doFilter()方法具有“有趣”的逻辑，例如特殊过滤或路由规则，则测试它们应该是测试此 void 方法的目的。 一般来说，如果 void 方法具有创建副作用的逻辑（除了在您的情况下仅调用chain.doFilter() ），那么测试所述 void 方法的目的将是测试该逻辑。 另一方面，这个逻辑可以也应该存在于一个非空的方法中（可能在另一个类中），它可以自己测试。

拥有 100% 的覆盖率（行或分支）并不是什么目标（特别是如果您不确保代码不仅被覆盖而且还被断言）。

Answer 3

它是一个完全有效的单元测试类和方法。

在chain.doFilter测试（ happyCookieResponseWrapper.wrap(response)的预期行为是否作为请求传递。没有技术happyCookieResponseWrapper.wrap(response) 。也许在请求中设置了一个 cookie。happyCookieResponseWrapper 的业务逻辑和功能不需要重复。有可能是基本重叠（设置了 cookie），但这发生在两个不同的级别。

顺便说一句，看到请求的响应包装器让我有点惊讶，但是当它编译时就可以了。

这是一个非常狭窄/琐碎的检查。 但是假设此代码在未来的某个时间被重新设计以使用其他包装类，这不符合正确的行为。 然后将快速找到回归错误，而不是从模糊描述的错误中听到并处理票证。