11.2 Publisher 合规测试

用例从哪里来

PublisherVerification 的测试方法名直接编码了规范条款：spec101 对应 §1.1，spec302 对应 §3.2，spec317 对应 §3.17。看失败方法名就能定位到规则，不需要猜。

方法名前缀有四种含义：

untested_ 不是「通过」，也不是「你的实现有问题」，它只是 TCK 没有写对应验证。统计通过率时不能把它算进去。

必测项与对应规则

下面这些都是 required_，方法名来自 1.0.4 的实际字节码，不是转述：

可选项主要是空流完成（optional_spec105_emptyStreamMustTerminateBySignallingOnComplete）、失败路径（optional_spec104_mustSignalOnErrorWhenFails）和多订阅者一致性（optional_spec111_*）。

一次真实运行

用一个合规的 Flux.range 包装做基线，createFailedPublisher() 返回 null：

===============================================
Command line suite
Total tests run: 38, Passes: 29, Failures: 0, Skips: 9
===============================================

9 个跳过里：

• 7 个是 untested_*：spec106、spec107（错误分支）、spec108、spec109（subscribe 抛非致命异常）、spec110、spec304、spec305；
• 2 个因为 createFailedPublisher() 返回 null：optional_spec104_mustSignalOnErrorWhenFails 和 required_spec109_mayRejectCallsToSubscribe...。

把 createFailedPublisher() 改成 Flux.error(new RuntimeException("boom")) 后：

Total tests run: 38, Passes: 31, Failures: 0, Skips: 7

多出的 2 个通过就是失败路径用例。这个对照说明：跳过数不是固定的，它取决于你提供了哪些可选能力。

还有一个影响用例行为的配置是 maxElementsFromPublisher()。它的默认值是 Long.MAX_VALUE - 1，TCK 会据此决定部分测试的元素规模。实现的缓冲或计数器承受不了超大值时，应显式覆盖成一个现实上界：

@Override
public long maxElementsFromPublisher() {
    return 10_000;
}

失败时怎么读信息

TCK 的断言信息通常直接说明现象。下面是两条典型输出（其中的超时数字随 TestEnvironment 配置变化）。

多发一个元素（createPublisher(n) 返回了 n+1 个）：

java.lang.AssertionError: Expected end-of-stream but got element [2]

失败方法是 required_createPublisher1MustProduceAStreamOfExactly1Element。修复不是改测试，而是让 createPublisher(1) 只发 1 个并在之后 onComplete。

忽略 request(0)（没有发 IllegalArgumentException）：

java.lang.AssertionError: Expected onError(java.lang.IllegalArgumentException) within 100 ms

失败方法是 required_spec309_requestZeroMustSignalIllegalArgumentException。修复是在 request 入口检查 n <= 0，并调用 onError(new IllegalArgumentException(...))，而不是静默返回或抛异常。

再看两个容易被误判的失败：

required_spec313 的失败通常不是逻辑错，而是内存泄漏：Publisher 在取消后仍持有 Subscriber，导致下游对象无法回收。这类问题在生产里比测试失败更隐蔽。

异步 Publisher 的额外注意

同步 Publisher 的测试基本是确定性的；异步 Publisher 会引入两个变量：

1. 信号必须最终可见。TCK 在测试线程上轮询 TestEnvironment 的探针；异步线程发完 onComplete 后如果没有正确的内存可见性（例如用普通字段做完成标志），测试线程可能一直等不到终止信号。
2. 超时要留足余量。默认 100ms 对线程池调度偏紧，建议在异步场景用 new TestEnvironment(5_000) 起步，再根据 CI 稳定性调整，而不是无条件调到几十秒。

PublisherVerification 没有 publisherExecutorService() 钩子——那是 Subscriber 两类基类才有的。异步 Publisher 的线程池由测试类自己创建，也由测试类在 @AfterClass 里关闭，否则 Surefire 可能挂住。

public class AsyncRangePublisherTckTest extends PublisherVerification<Integer> {

    private ExecutorService executor;

    public AsyncRangePublisherTckTest() {
        super(new TestEnvironment(5_000));
    }

    @Override
    public long maxElementsFromPublisher() {
        // TCK 的 spec317 用例会按 Long.MAX_VALUE 附近的规模调用 createPublisher；
        // AsyncRangePublisher 用 int 计数，必须先声明现实上界，否则 (int) 溢出
        return 10_000;
    }

    @Override
    public Publisher<Integer> createPublisher(long elements) {
        int count = Math.toIntExact(elements);
        return new AsyncRangePublisher(1, count + 1, executor());
    }

    @Override
    public Publisher<Integer> createFailedPublisher() {
        return null;
    }

    @AfterClass
    public void tearDown() {
        if (executor != null) {
            executor.shutdownNow();
        }
    }

    private ExecutorService executor() {
        if (executor == null) {
            executor = Executors.newSingleThreadExecutor();
        }
        return executor;
    }
}

上面的 executor() 是示例自己的资源管理，@AfterClass 的 tearDown() 负责关闭，避免 Surefire 进程挂住。shutdownNow() 会中断仍在运行的任务；如果测试需要等任务结束，改用 shutdown() 加 awaitTermination()。

小结

阅读导航

上一篇：11.1 RS TCK：测试环境搭建

下一篇：11.3 Subscriber 与 Processor 合规测试