我正在开发一个基于存储库模式的域模型，并且我作为 TDD 一部分的所有单元测试都针对测试存储库。
我的问题是：我在什么时候针对存储库的 SQL 版本创建集成测试？
我担心从对象（测试存储库）访问数据的代码可以正常工作。但是数据库版本（SQL 存储库）在幕后是如此不同，以至于我在 SQL 存储库中的重要代码最终将无法工作并且本身未经测试。我如何确保它按预期工作？我是否遗漏了有关流程的某些内容？
问候。
【问题讨论】：
标签： c# unit-testing tdd repository-pattern
您应该进行模拟存储库的测试（就像您所做的那样），它不会查询数据库本身，但会像查询一样返回结果。这些是调用存储库函数的函数的测试。
但它也很有用，建议进行检查数据库本身的测试，并检查它们是否返回了应有的结果。它们也应该是“单元测试”，而不是依赖于其他东西。尽量不要依赖于数据库处于确定状态，而是进行设置以构建数据库初始状态。它们可能会更慢，并且可能不会在每次提交和构建时运行（我的意思是，不要运行如果真的需要很多时间）。
最后，在你的集成测试中，做所有你应该做的事情。
【讨论】：
在我看来，只要您拥有被测单元所依赖的相应数据库代码，就可以继续并添加使用真实存储库的集成测试。伪造和存根使单元测试更容易，并允许您专注于代码的特定方面，而不会因外部依赖项而感到沮丧并正确设置它们。但是，归根结底，您不会运送带有存根、赝品和模拟物的产品。交付的产品具有真正的依赖关系和组件，所有这些都必须协同工作。因此，无论何时运行测试，都需要知道应用程序的某些部分是否协同工作。如果我的应用程序的一部分无法持久保存对数据库的更改，我想尽快知道。因此，如果您的外部依赖项（在您的案例中是数据库）处于为您的代码提供某种程度的功能和价值的水平，请继续添加一套集成测试。
请注意，运行集成测试通常需要比单元测试更长的时间。因此，您可能只想在 CI 构建期间运行单元测试。这样，您可以更快地获得有关构建和代码库健康状况的反馈。但是，您应该在夜间构建中包含集成测试，以便了解您的代码在现实中是如何工作的。
【讨论】：