作者:来自 Elastic piotrprz

在创建应该使用 Elasticsearch 进行搜索、数据聚合或 BM25/vector/search 的软件时,创建至少少量的集成测试至关重要。虽然 "模拟索引" 看起来很诱人,因为测试甚至可以在几分之一秒内运行,但它们实际测试的不是与真实 Elasticsearch 的交互,而是我们对 Elasticsearch 的想象。这可能会在生产中得到严格的验证,特别是在集群更新之后 :wink:
为了减轻集成测试最明显的缺点,至关重要的是使用数据初始化 Elasticsearch,这种方式对于日常生产场景来说可能不是最佳的,但对于测试设置来说却非常有效。
更多有关测试的文章:
不要重新创建容器
依赖 Elasticsearch 测试你的功能可能只需要很少的时间,比如几分之一秒。那么在测试之间重新启动 Elasticsearch 并不是一个明智的想法,因为你将额外花费几十秒钟来等待 ES 启动。
只需在测试之前启动一次 Elasticsearch,在每次测试后进行清理,并在每次测试之前初始化数据。
提示 :如果您在 Java 等语言中使用 Elasticsearch 的 Testcontainers 模块,请确保该字段是 @Container static 或至少在 @BeforeAll 中启动。
测试之前,cURL 是你的好朋友
在生产代码(我们正在测试)中使用客户端库是一个明智的选择。然而,在准备测试环境时,采用更为复杂的方法可能会有好处,因为生产用例和测试数据设置的需求并不 100% 相同。使用 cURL 管理 Elasticsearch 中的数据并不是什么难事,正如我们在之前的文章中看到的那样:如何使用 cURL Elasticsearch:进入 Shell。
另一个好处是 cURL 与编程语言无关,因此来自不同技术栈的人可以更容易理解测试。
从 Testcontainers 使用 cURL 并不比 Bash 困难多少,例如,如果你需要删除书籍索引,可以这样做:
elasticsearch.execInContainer(
"curl", "https://localhost:9200/books", "-u", "elastic:changeme",
"--cacert", "/usr/share/elasticsearch/config/certs/http_ca.crt",
"-X", "DELETE"
)
尽可能批量
在很多情况下,索引单个文档是有意义的,但加载测试数据不是其中之一。无需发出 1000 个请求来索引每个文档,只需运行一个包含 1000 个文档的 _bulk 请求即可。即使使用测试容器也不是什么难事:
elasticsearch.execInContainer(
"curl", "https://localhost:9200/_bulk?refresh=true", "-u", "elastic:changeme",
"--cacert", "/usr/share/elasticsearch/config/certs/http_ca.crt",
"-X", "POST",
"-H", "Content-Type: application/x-ndjson",
"--data-binary", "@/tmp/books.ndjson"
)
通过这种方法,您甚至可以在一次调用中将文档添加到许多线索中!
尽量本地化
CPU缓存比内存快得多,本地存储通常比网络快。如果你有十个用例都依赖同一份数据集,那就没有必要每次都把同样的数据发送到同一个容器里(毕竟我们不会每次测试都创建新容器,对吧?)
因此,在创建容器时,加上 .withCopyToContainer(...)
,这样你就可以把文件一次性复制到容器 ,然后像上面那样直接用 _bulk
处理。这大概是这样的:
static ElasticsearchContainer elasticsearch =
new ElasticsearchContainer(ELASTICSEARCH_IMAGE)
.withCopyToContainer(MountableFile.forHostPath("src/test/resources/books.ndjson"), "/tmp/books.ndjson");
这在设置(如 CI)中尤其有意义,其中容器运行时不是本地的,而是从不同的机器注入的。
回顾
这里提出的想法提醒我们,永恒的 IT 口头禅 "不要重复自己" 也适用于初始化测试数据。将数据批量保存在本地,这样你就可以节省执行集成测试所需的大量时间。欲了解更多见解,请随意探索 Github repo,其中包含更多示例和分支。