测试 Elasticsearch，现在变得更简单了

作者来自 Elastic Piotr Przybyl解释由于 Elasticsearch 9.x、现代 Java 客户端以及 Testcontainers 2.x 的改进Elasticsearch 集成测试如何变得更加简单。上手体验 Elasticsearch深入了解我们在 Elasticsearch Labs 仓库中的示例 notebooks开始免费的云端试用或者现在就在本地机器上尝试 Elastic。当我最初写关于使用 Testcontainers for Java 测试 Elasticsearch 时重点非常务实如果你关心正确性就应该针对真实节点进行测试如果你关心信心你的集成测试应该尽可能接近生产环境如果你关心可维护性你的设置不应该变成一个由 mocks 和假设组成的迷宫。这一理念并没有改变。然而改变的是现在实现这一目标所需的努力已经大大减少。借助 Elasticsearch 9.x、现代 Java 客户端以及 Testcontainers 2.x编写集成测试的体验明显更加顺畅就像一层附带的复杂性被悄然移除了。本文附带的示例刻意保持简单可以在这里找到。它并不试图展示复杂的索引策略或精细的数据管道相反它专注于基础因为正是在这些基础之处改进最为明显。当工具不再成为阻碍时任何维护过几年测试套件的人都会认出这种模式你引入一个新库一个传递依赖引入了一些意想不到的东西不久之后你就在不同测试引擎版本之间周旋而不是在编写测试。在 Testcontainers 2.x 中这种周旋基本消失了。依赖结构更加清晰模块更加明确与旧测试框架的意外耦合不再悄悄出现。从实际角度来看在测试中添加 Elasticsearch 支持现在就像声明以下内容一样简单dependency groupIdorg.testcontainers/groupId artifactIdtestcontainers-elasticsearch/artifactId version2.0.3/version scopetest/scope /dependency并且如果你正在使用 JUnit Jupiter 集成dependency groupIdorg.testcontainers/groupId artifactIdtestcontainers-junit-jupiter/artifactId version2.0.3/version scopetest/scope /dependency不需要添加各种排除项不需要屏蔽旧版引擎也不会再有那种担心在下次升级时某些隐藏问题突然浮现的不安感。配置变得几乎平淡无奇而在构建工具的语境中这反而是一种优点。一个具有完整安全性的真实 Elasticsearch 节点在演示测试中我们使用官方的 Elasticsearch 9.3.1 Docker 镜像var container new ElasticsearchContainer(docker.elastic.co/elasticsearch/elasticsearch:9.3.1); container.start();乍一看这可能与较旧的示例类似但细微的差别在于我们不再需要做的事情。我们不再禁用安全性不再绕过 SSL也不再为了让测试更方便而简化环境。相反一旦容器启动我们就构建一个使用 REST API 并进行正确认证的客户端try (var client ElasticsearchClient.of(c - c .host(https:// container.getHttpHostAddress()) .usernameAndPassword(elastic, ElasticsearchContainer.ELASTICSEARCH_DEFAULT_PASSWORD) .sslContext(container.createSslContextFromCa()) )) {这里特别值得一提的是客户端构建本身已经变得多么简洁。在早期版本中创建一个 Elasticsearch 客户端通常意味着需要处理多个中间对象、显式配置传输层、封装底层客户端并为这些本质上只是“管道工作”的内容编写一定量的代码。而现在信噪比显著提高。builder 封装了必要的细节容器提供客户端所需的一切最终配置可以用几行清晰易读的代码完成。同样重要的是ElasticsearchClient 是 AutoCloseable这意味着它可以自然地与 try-with-resources 集成在无需额外繁琐操作的情况下确保正确清理。其生命周期是显式的、简洁的且自包含的这正是集成测试所需要的——关注行为而不是基础设施管理。容器暴露了构建合法且安全连接所需的一切而客户端可以自然地与之集成这意味着测试环境在所有关键方面都与生产环境保持一致同时不会给开发者带来额外的认知负担。这种在真实性与简洁性之间的对齐也许是最有意义的改进之一。类型化 API 改变了测试的特性Elasticsearch Java 客户端的演进也重塑了集成测试的阅读和体验方式。过去的方法通常需要解析 JSON 响应或处理松散类型结构而现代客户端提供了基于 builder 的强类型 API在编译期就能引导你构建合法的请求结构。在示例中我们执行了一个简单的集群健康检查var health client.cluster().health(); Assertions.assertEquals(docker-cluster, health.clusterName()); Assertions.assertEquals(HealthStatus.Green, health.status());这里引人注目的不是操作的复杂性而是几乎没有阻力。不需要从 maps 中手动提取数据不需要基于未类型化字符串值来编写断言也不需要绕到低层响应处理。测试代码看起来与应用代码几乎没有区别这在某种程度上强化了这样一个观点集成测试并不是一类拥有不同规则的特殊代码而只是同一 API 的另一种使用者。当生产代码与测试代码之间的边界变得更模糊时信心几乎会自然而然地提升。将测试当作一个故事来阅读如果你查看完整的测试用例Test void newClientTest() throws IOException { try (var container new ElasticsearchContainer(docker.elastic.co/elasticsearch/elasticsearch:9.3.1)) { container.start(); try ( var client ElasticsearchClient.of(c - c.host(https:// container.getHttpHostAddress()) .usernameAndPassword(elastic, ElasticsearchContainer.ELASTICSEARCH_DEFAULT_PASSWORD) .sslContext(container.createSslContextFromCa()))) { HealthResponse health client.cluster().health(); Assertions.assertEquals(docker-cluster, health.clusterName()); Assertions.assertEquals(HealthStatus.Green, health.status()); } } }你会注意到它读起来不像一个配置脚本而更像一个简短的叙述我们定义容器。我们启动容器。我们构建客户端。我们调用真实 API。我们断言结果。支撑性的基础设施逐渐淡出背景使测试的意图清晰可见。这种清晰性并非偶然而是 Testcontainers 和 Elasticsearch 客户端一系列渐进改进的累积效果。高级模式仍然适用在之前的文章《使用真实 Elasticsearch 的更快集成测试》和《使用真实 Elasticsearch 的高级集成测试》中讨论的更高级技术并没有过时。复用容器以加速大型测试套件、自定义集群设置、预加载索引或测试基于角色的访问场景仍然完全有效并且在许多情况下是必不可少的。改进之处在于基础体验。最简单的集成测试——仅需要一个真实节点和一个真实客户端——不再需要防御性配置或依赖折腾。它默认就是简洁、表达力强且接近生产环境的。无声的进步生态系统并没有发生戏剧性的重写也没有迫使人们重新思考一切的破坏性迁移指南。相反是 API 和依赖的持续优化每个版本都在这里抹平一个棱角在那里消除一个意外。结果并不浮夸但却切实可感。现在为 Elasticsearch 编写集成测试更像是在一个缩小版的真实系统上进行操作而不是在组装一个测试工具链。有时候进步会高调地宣告自己。有时候它悄然到来以代码更易读、解释更少的形式出现。在这个案例中属于后者而对于那些关注干净、可靠集成测试的人来说这已经足够了。那么如果我们也能对 Kibana 做类似的事情会怎样听起来很有吸引力吗敬请期待原文https://www.elastic.co/search-labs/blog/elasticsearch-integration-tests