第3节：Turbine安装与环境配置

说到Turbine的安装，其实远没有想象中那么复杂。我刚开始接触这个库的时候，也踩了不少坑，后来总结出一套比较稳的流程。今天就把这些经验掰开了揉碎了讲给你听。

核心观点：Turbine本质上是一个轻量级的Java库，它不依赖任何外部服务，只要你把Maven或Gradle的依赖配对，三分钟就能跑起来。

3.1 环境依赖与版本匹配

先看看你的机器上缺什么。嗯，这东西完全跑在JVM上，所以Java是必须的。我个人的习惯是至少用Java 11，因为Turbine从0.7版本开始就全面拥抱了Java模块化系统。

你想想看，如果你还在用Java 8，某些反射API会抛警告，虽然也能跑，但调试时噪声太大。我曾经在项目里就因为Java版本太低，浪费了两个小时查一个诡异的ClassNotFoundException——最后发现是模块路径没配好。

依赖	最低版本	我推荐版本
Java	Java 8	Java 11 / Java 17
Maven	3.6.3	3.9.6
Gradle	6.8	8.x

注意！如果你用的是Gradle 7以下版本，必须手动开启--release参数，否则Turbine的Jigsaw模块会报module not found。我去年在CI环境里就吃过这个亏。

3.2 获取Turbine——Maven方式

最直接的方法就是往pom.xml里扔一条依赖。别急着复制，先看一眼你的turbine.version变量定义在哪里。我个人喜欢用properties统一管理版本号，方便升级。

<properties>
    <turbine.version>0.8.1</turbine.version>
</properties>

<dependency>
    <groupId>io.fluidsonic.turbine</groupId>
    <artifactId>turbine-core</artifactId>
    <version>${turbine.version}</version>
    <scope>test</scope>
</dependency>

scope别搞错——这玩意儿是测试用的，放到test scope下最干净。我以前有个同事图省事放在compile scope里，结果项目打包时把Turbine的依赖全打进去了，生产包体积大了4MB，还被安全扫描扫出了几个无关漏洞。

3.3 Gradle配置——更简洁

如果你用Gradle，那更爽。两行搞定：

dependencies {
    testImplementation("io.fluidsonic.turbine:turbine-core:0.8.1")
}

嗯，这里要注意：Gradle的testImplementation和Maven的test scope机制一样，但Gradle不会自动把传递依赖的Javadoc或sources拉下来。如果你想在IDE里看Turbine的源码，可以加一句：

testImplementation("io.fluidsonic.turbine:turbine-core:0.8.1:sources")

不过我不建议你这么干——IDE通常会自动下载源码，你手动指定反而可能和缓存打架。

3.4 验证安装——写个简单测试

配好依赖后，跑一个最简单的用例，看看环境通不通。写个JUnit 5测试类：

import io.fluidsonic.turbine.FlowTurbine;
import org.junit.jupiter.api.Test;

class TurbineSetupTest {

    @Test
    void testBasicInstallation() {
        // 用Turbine收集一个简单Flow
        val result = flowOf("hello", "world")
            .test()  // 这是Turbine的扩展方法
            .toList();

        assertThat(result).containsExactly("hello", "world");
    }
}

如果这能通过，那恭喜你——Turbine已经成功安家。为什么我选flowOf做测试？因为Flow本身就是Turbine的核心操作对象。你想想看，如果连最基本的Flow都收不了，后面的回归测试方案根本跑不起来。

快速检查清单：
Java版本 ≥ 11（推荐17）
Maven/Gradle能正常下载依赖（走内网私服的话要配镜像）
JUnit 5基础测试通过
IDE的Lombok注解处理已开启（Turbine内部用了少量Lombok）

3.5 配置文件与日志调优

Turbine本身不需要任何配置文件——这是它的优点。但你在实际项目中，往往需要配合logback-test.xml或者application.yml来调整日志等级。为什么呢？因为在回归测试时，如果Turbine内部出现异常，默认日志可能只输出一行WARN，你根本看不出是哪里出了问题。

我一般这样配Logback：

<logger name="io.fluidsonic.turbine" level="DEBUG"/>

这样Turbine在emit、cancel、error时的内部状态都会打印。不过别在生产环境开DEBUG，它会刷屏。测试环境没问题。

3.6 使用BOM统一版本

如果你们项目里同时用了Turbine的其他模块（比如turbine-ktor、turbine-test），我强烈建议使用Maven BOM（Bill of Materials）来管理版本。这样所有模块的版本号都从同一个地方获取，不会出现微服务A用0.8.0、微服务B用0.8.1这种悲剧。

我去年接手一个遗留项目时，就发现两个模块的Turbine版本差了三个小版本，结果cancel()方法的签名不一致，编译不报错，但跑回归测试时总超时——查了两天才找到根因。

Maven BOM配置示例：

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.fluidsonic.turbine</groupId>
            <artifactId>turbine-bom</artifactId>
            <version>0.8.1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

然后在子模块里只写groupId和artifactId，版本号自动继承。

3.7 常见问题与避坑指南

问题1：依赖下载超时或找不到 artifact
我曾经在内网环境里折腾了一下午，最后发现是Maven的settings.xml里配置了私服，但私服没有同步Maven Central的Turbine包。解决办法是：先用mvn dependency:purge-local-repository清除缓存，然后手动将私服URL替换为中央仓库镜像（如阿里云镜像）。

问题2：IDE报错 "Unresolved reference: test"
这是Kotlin扩展函数没被识别的典型症状。检查一下你的IDE是否开启了Kotlin插件，并且turbine-core的scope确实是test。如果都没问题，就执行一次./gradlew clean build——有时候是IDE的缓存作祟。

问题3：FlowTurbine测试一直阻塞不结束
别慌。大概率是因为你的Flow生产了无限元素而Turbine没有调用cancel()。我刚开始用的时候就犯过这个错——写了一个flow { while(true) { emit(1) } }，结果测试跑了半小时还没停。记住：在测试中一定要给Flow加上timeout()，或者用.test().cancel()显式停止。

我的常用模板：每次新建测试类，我都复制下面这段作为脚手架：

@Test
fun `should complete within timeout`() = runTest {
    flowOf(1, 2, 3)
        .test()
        .awaitItem(1)
        .expectComplete()
}

3.8 小结

Turbine的安装配置就这么简单。你看，从检查Java版本到跑通第一个测试，拢共也就四五个步骤。你只要记住：scope别搞错、版本别打架、日志配DEBUG，基本不会出大问题。

我个人习惯是把这份配置模板放在公司内部的知识库wiki里，新同学来了直接复制粘贴，5分钟就能开始写回归测试。希望今天的分享，能让你少走我当年走过的弯路。