【Go 测试之道】05 集成测试（上）：用 Testcontainers 驯服数据库

大家好，我是Tony Bai。

欢迎来到《Go 测试之道：从测试金字塔到高级实践》的第五讲。

在上一讲中，我们成功地利用构建约束（Build Tags）为我们的测试“战场”划分出了清晰的 unit 和 integration 两个战区。这是一个至关重要的战略步骤，它让我们可以按需调度，隔离快慢测试。

但是，一个尖锐的问题依然摆在我们面前：我们为 repository 层创建的 link_repository_int_test.go文件，至今还只有一行 t.Skip()。我们到底该如何运行它？

要运行它，就必须有一个真实的 PostgreSQL 数据库。这引出了集成测试中最核心、也最痛苦的难题——如何管理这些外部依赖？

在过往，我们通常只有几种痛苦的选择：

1. 共享的“测试”数据库： 团队共同维护一个或多个用于测试的数据库实例。

• 痛点： 极度脆弱！任何人的测试都可能污染数据，导致其他人的测试莫名其妙地失败。测试无法并行，因为会相互干扰。环境的维护和清理是一场永无休止的噩梦。

• 本地手动安装： 要求每个开发者都在自己的机器上安装并配置一个 PostgreSQL。

• • 痛点： “在我机器上是好的啊！”。版本不一致、配置差异、操作系统不同……这些问题会让测试结果变得不可靠，违背了自动化测试“一致、可重复”的核心原则。CI/CD 环境的配置也变得异常复杂。

• 使用内存数据库： 比如在 Java 世界里用 H2 替代 MySQL，或者在 Go 里用 mattn/go-sqlite3 替代 PostgreSQL。

• • 痛点： “虚假的和平”。内存数据库和真实数据库在 SQL 方言、事务行为、约束支持等方面存在大量细微差异。通过了内存数据库测试的代码，在生产环境的真实数据库上依然可能失败。

  这些“旧世界”的方案，都无法完美地解决问题。我们需要的是一种全新的、更现代的范式。

  本讲，我们将深入testcontainers 这一“新世界”的利器，并亲手为我们的 Repository 层构建第一个真正意义上的自动化集成测试。

  

  测试的“新世界”——Testcontainers 与“临时基础设施”

  上面我们探讨的集成测试在“旧世界”中面临的种种困境：环境不一致、数据相互污染、维护成本高昂。这一切问题的根源，都在于测试代码与其所依赖的基础设施（数据库、缓存等）是分离的、静态的。

  我们需要一种全新的范式，一种能让基础设施变得像普通对象一样，可以按需创建、使用和销毁的范式。这，就是 Testcontainers 带来的革命。