本文旨在指导如何高效地对okhttp拦截器进行单元测试，特别是当拦截器负责修改请求头时。我们将探讨传统测试方法在此场景下的局限性，并介绍一种利用spock框架和模拟（mock）技术，在隔离环境中精确验证拦截器对请求头所做修改的专业方法。通过模拟拦截器链并使用参数约束，确保拦截器按照预期行为修改了请求。
OkHttp拦截器与请求头修改
在OkHttp网络请求库中，拦截器（Interceptor）是一个强大的机制，允许开发者在请求发送和响应接收之间插入自定义逻辑。常见的应用场景包括添加认证信息、日志记录、重试机制或修改请求头。
考虑一个典型的场景，我们需要在每个传出请求中添加一个Authorization请求头。以下是一个实现此功能的拦截器示例：
package de.scrum_master.stackoverflow.q74575745;
import okhttp3.Interceptor;
import okhttp3.Request;
import okhttp3.Response;
import java.io.IOException;
class AuthRequestInterceptor implements Interceptor {
@Override
public Response intercept(Interceptor.Chain chain) throws IOException {
Request original = chain.request();
// 请求定制：添加请求头
Request.Builder requestBuilder = original.newBuilder()
.header("Authorization", "auth-value");
Request request = requestBuilder.build();
return chain.proceed(request);
}
}这个AuthRequestInterceptor拦截器接收原始请求，通过newBuilder()创建一个新的请求构建器，添加Authorization头，然后构建新的请求并调用chain.proceed(request)将其传递给链中的下一个拦截器或最终的网络层。
传统测试方法的局限性
在编写拦截器的单元测试时，一个常见的误区是尝试通过构建一个完整的OkHttpClient实例，然后执行一个模拟请求，并期望从返回的Response对象中验证请求头。例如：
// 这是一个不推荐的测试方法示例
class AuthRequestInterceptorTestIncorrect extends Specification {
AuthRequestInterceptor authRequestInterceptor = new AuthRequestInterceptor();
OkHttpClient okHttpClient;
void setup() {
okHttpClient = new OkHttpClient().newBuilder()
.addInterceptor(authRequestInterceptor)
.build();
}
def "Get Authorization in to header - Incorrect Approach"() {
given:
HashMap headers = new HashMap<>()
when:
Request mockRequest = new Request.Builder()
.url("http://1.1.1.1/heath-check")
.headers(Headers.of(headers))
.build()
Response res = okHttpClient.newCall(mockRequest).execute() // 这里的execute会尝试进行网络请求
then:
// 期望从响应中获取请求头，这是错误的
res.headers("Authorization")
}
} 这种方法的根本问题在于：
- 网络依赖： okHttpClient.newCall(mockRequest).execute()会尝试发起真实的网络请求（即使URL是1.1.1.1，它仍会尝试连接），这违背了单元测试“隔离”的原则。
- 验证对象错误： Response对象代表的是服务器返回的数据，它不包含拦截器修改后、发送到网络层的Request的详细信息。我们无法直接从Response中验证拦截器对Request所做的修改。我们需要验证的是intercept方法内部，拦截器将修改后的Request传递给了chain.proceed()。
使用Spock和Mock进行隔离测试
为了在隔离环境中精确测试拦截器对请求的修改，我们需要模拟Interceptor.Chain接口。Interceptor.Chain是拦截器与链中其他部分交互的接口，通过模拟它，我们可以控制chain.request()的返回值，并验证chain.proceed(Request)被调用的参数。
以下是使用Spock框架实现这一目标的专业测试方法：
package de.scrum_master.stackoverflow.q74575745
import okhttp3.Interceptor
import okhttp3.Request
import spock.lang.Specification
class AuthRequestInterceptorTest extends Specification {
def "request contains authorization header"() {
given: "a mock interceptor chain returning a prepared request without headers"
// 1. 模拟 Interceptor.Chain
def chain = Mock(Interceptor.Chain) {
// 2. 定义 chain.request() 的行为：返回一个不带Authorization头的原始请求
request() >> new Request.Builder()
.url("http://1.1.1.1/heath-check")
.build()
}
when: "running the interceptor under test"
// 3. 实例化并运行被测试的拦截器
new AuthRequestInterceptor().intercept(chain)
then: "the expected authorization header is added to the request before proceeding"
// 4. 验证 chain.proceed() 被调用，并检查其参数
// 1 * 表示期望该方法被调用一次
// { Request request -> ... } 是 Spock 的参数约束，允许我们检查传递给方法的 Request 对象
1 * chain.proceed({ Request request ->
// 验证 Request 对象的 Authorization 头是否符合预期
request.headers("Authorization") == ["auth-value"]
})
}
}代码解析与注意事项
- Mock(Interceptor.Chain): Spock框架提供Mock方法来创建一个Interceptor.Chain的模拟对象。这个模拟对象将取代真实的链实现，使我们能够完全控制其行为。
- request() >> new Request.Builder()...build(): 这是Spock的“桩（stubbing）”语法。它定义了当chain.request()方法被调用时，应该返回什么。在这里，我们让它返回一个原始的、不包含Authorization头的请求，模拟拦截器接收到的初始请求。
- new AuthRequestInterceptor().intercept(chain): 这是执行被测试拦截器核心逻辑的地方。我们将模拟的chain对象传递给它。
- *`1 chain.proceed({ Request request -> ... })`**: 这是Spock的“交互验证（interaction verification）”功能。
- 1 * 表示我们期望chain.proceed()方法被调用且仅被调用一次。
- { Request request -> ... } 是一个闭包（closure），作为proceed方法的参数约束。Spock会将实际传递给proceed方法的Request对象赋值给闭包中的request变量，我们可以在闭包内部对这个request对象进行断言。
- request.headers("Authorization") == ["auth-value"]：这是关键的断言。它检查被拦截器修改后，并传递给chain.proceed()的Request对象是否包含预期的Authorization头，并且其值为"auth-value"。
总结
通过模拟Interceptor.Chain并利用Spock框架强大的参数约束能力，我们可以对OkHttp拦截器进行高效、隔离且精确的单元测试。这种方法避免了对真实网络环境的依赖，专注于验证拦截器本身的业务逻辑，确保它按照预期修改了请求，从而提高了测试的可靠性和维护性。在测试拦截器时，核心在于理解其职责，并验证其对Request或Response对象的具体修改，而不是通过间接的、可能受外部因素影响的方式进行验证。
