Pgtestdb 的模板克隆测试方法速度很快

昨天的 Cup o’ Go 提醒我 Peter Downs 的 pgtestdb 的存在，这是一个 Go/Postgres 测试包。 pgtestdb 是围绕 Postgres 模板数据库构建的，这是一个内置功能，您可以直接从普通的 psql shell 中尝试： CREATE DATABASE dbname TEMPLATE template_to_copy;复制模板非常快，比从头开始迁移测试数据库快得多，也比一些项目现在使用的一些基于 Docker 的重量级技术快得多。在底层，Postgres 枚举模板的关系，并以 8 kB 页面块的形式复制其物化堆、索引和目录文件。我记得几年前读过这个功能，但说实话，我忘记了它的存在，我很好奇它与其他测试方法相比表现如何，所以我将 Codex 拼接 pgtestdb 到 River 的测试套件中，看看它的表现如何。我认为 River 的测试方法或多或少是速度和可靠性的黄金标准。它使用一组自定义的测试助手，根据模式隔离测试用例，这种方法比测试事务慢，但有一些优点： 保留测试状态以在测试失败时进行检查。允许测试数据库范围的功能，例如监听/通知。启用围绕多个事务交互和回滚的测试边缘。在 Postgres 中，模式比数据库更轻，因此基于模式的方法具有这一优势。但是，您无法克隆模式，因此基于模式的方法必须每次都运行迁移，这使得 pgtestdb 在这方面具有明显的优势。这应该给我们一个有趣的比较。以下是我得到的结果： Method Count Mean p90 p95 Max pgtestdb clone 466 98.4ms 247.4ms 299.5ms 465.1ms Create + migrate schema 81 99.4ms 152.1ms 209.0ms 327.0ms 我们发现两种方法的时间非常相似，大约为 100 ms 的设置时间。我一直认为任何涉及创建新数据库的事情都会相对较慢，所以我对 pgtestdb 的方法的速度如此之快感到惊讶。我将把 River 的测试留在其现有的基于模式的方法上，因为它已经很快了，并且测试模式隔离对于验证 River 的基于模式的配置是否如宣传的那样有用，但我将在我们的文档中添加 pgtestdb 的建议，特别是对于旨在测试端到端的用户（即由客户端插入的作业 → 由工作人员完全完成）。我在上面一点点打沙袋。虽然基于模式的方法的设置时间与 pgtestdb 的完整数据库相似，但总体而言，测试套件的运行速度比前者快了约 3.5 倍： Method Wall time pgtestdb clone 51.07s Create + migrate schema 14.54s 但这并不是因为模式快得多。 River 的测试助手有一个有用的优化，因为它们将创建 Go 的即时并行化所需的尽可能多的测试模式，但在测试用例完成时将它们集中起来。如果无人认领的模式已准备就绪，测试用例将清理并重用它，而不是从头开始生成新的模式。这说起来容易做起来难，因为您需要考虑诸如模式版本之类的细节——即，在跨模式版本进行测试时，每个测试用例必须仅重用其期望的同一版本上的模式。当然，这是非常可行的，但需要考虑一下。我在 LLM 之前就编写了 River 的实现，我花了几天时间才排除所有错误。我提到重用是因为它也可以使用 pgtestdb 来完成，可能作为包的一部分，或者作为调用它的项目中的增强。 100 毫秒引导测试数据库相当快，但如果您正在构建一个将进行 10,000 个测试的完整应用程序，那么理想情况下您希望测试设置速度快 10 倍。重用可将其降低至 10-20 毫秒，并且更符合测试事务。