Flink 1.15.1集成测试未依赖指定组件的原理及正确性疑问

我使用Flink 1.15.1与JUnit5编写了一段集成测试代码（如下所示），但未引入flink-test-utils依赖，也未使用MiniClusterWithClientResource静态实例，测试却能正常运行。想了解该测试的运行原理，以及这种做法是否会导致测试存在关键缺陷，毕竟文档明确要求依赖上述组件。

package com.mypackage;

import static org.junit.jupiter.api.Assertions.assertTrue;

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.streaming.api.functions.sink.SinkFunction;
import org.junit.jupiter.api.Test;

public class ExampleIntegrationTest {

  @Test
  public void testIncrementPipeline() throws Exception {
    StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

    // configure your test environment
    env.setParallelism(2);

    // values are collected in a static variable
    CollectSink.values.clear();

    // create a stream of custom elements and apply transformations
    env.fromElements(1L, 21L, 22L).map(n -> n + 1).addSink(new CollectSink());

    // execute
    env.execute();

    // verify your results
    assertTrue(CollectSink.values.containsAll(List.of(2L, 22L, 23L)));
  }

  // create a testing sink
  private static class CollectSink implements SinkFunction<Long> {

    // must be static
    public static final List<Long> values = Collections.synchronizedList(new ArrayList<>());

    @Override
    public void invoke(Long value, SinkFunction.Context context) throws Exception {
      values.add(value);
    }
  }
}

一、测试运行的原理 #

• 自动启用本地执行模式：当调用StreamExecutionEnvironment.getExecutionEnvironment()时，Flink会自动识别当前运行环境。在JUnit测试这种非集群场景下，会默认初始化LocalExecutionEnvironment，它不需要额外的测试集群依赖，直接在当前JVM进程内启动迷你Flink运行时。
• 本地运行时的执行逻辑：本地模式会在当前进程中启动JobManager和对应并行度的TaskManager线程，处理作业的提交、调度和执行，整个流程完成后自动销毁这些组件，不需要手动管理集群生命周期。
• 静态Sink跨线程共享数据：CollectSink的静态同步列表在同一个JVM内的线程间可见，Task线程执行sink的invoke方法时，能直接将数据写入该列表，测试主线程可以读取列表内容进行断言验证。

二、这种做法的关键缺陷 #

• 与生产环境偏差大：本地模式的执行逻辑和真实集群（如Yarn、K8s）存在诸多差异，比如网络通信模型、状态后端的持久化机制、故障恢复流程等，测试通过不代表生产环境能正常运行。
• 资源与配置无法精准控制：MiniClusterWithClientResource支持自定义集群配置（如TaskManager数量、内存分配、状态后端类型），而本地模式只能依赖当前机器的默认资源，复杂作业可能因资源限制出现和集群不一致的问题。
• 测试隔离性不足：静态变量CollectSink.values虽然在测试前做了清理，但如果JUnit5开启并行测试，多个测试用例会同时操作该列表，引发线程安全问题；而MiniClusterWithClientResource会为每个测试用例提供独立的集群环境，彻底避免用例间的交叉污染。
• 缺失专业测试工具支持：flink-test-utils提供了状态校验、作业故障模拟、时间控制（处理/事件时间测试）等实用工具，没有这些工具，复杂业务场景（如状态恢复、窗口计算）的测试很难覆盖。
• 测试可信度降低：官方文档要求使用指定测试组件，是因为这些组件经过专门设计，能保证测试的可靠性、一致性和可维护性，跳过它们会让测试的参考价值大打折扣。

内容的提问来源于stack exchange，提问作者Dan