测试真实存储库

Question

我已经设置了单元测试，用于测试假存储库和使用假存储库的测试。

但是如何测试访问数据库的真实存储库呢？如果将其留给集成测试，那么它似乎没有直接测试，可能会遗漏问题。

我在这里错过了什么吗？

Answer 1

好吧，集成测试只会测试文本持久性或从持久性层检索数据。如果您的存储库正在执行有关该数据的任何逻辑（验证，如果找不到对象则抛出异常等），可以通过伪造持久层返回的内容进行单元测试（是否返回查询对象，返回代码，或其他东西）。您的集成测试将确保代码可以物理地持久化/从持久性中检索数据，就是这样。任何类型的测试逻辑都应属于单元测试。

然而，有时，逻辑可能存在于持久层本身（例如存储过程）中。这可能是为了提高效率，或者它可能只是遗留代码。这对于正确的单元测试来说更难，因为您只能通过访问数据库来访问逻辑。在这种情况下，最好尽可能多地尝试将逻辑移动到代码库中，以便可以更轻松地对其进行测试。可能存在用于这些场景的单元测试框架，但我不了解它们（仅仅是出于缺乏经验）。

Answer 2

您是否可以设置一个真实的存储库来测试假数据库？

无论你做什么，这个都是集成测试，而不是单元测试。

Answer 3

我肯定建议在合理范围内针对DAL进行集成测试。

我们不使用存储库模式本身（令我们懊恼），但我们对类似类（搜索者）的政策如下：

• 如果方法使用O / RM调用从数据库中进行简单检索，请不要对其进行测试。
• 如果该方法使用O / RM的查询构建功能，请对其进行测试。
• 如果方法包含字符串（例如列名），请对其进行测试。
• 如果方法调用存储过程，请对其进行测试。
• 如果方法包含逻辑，请测试它。但要尽量避免逻辑。
• 如果方法绕过O / RM并使用原始SQL，请对其进行测试。但是要尽量避免这种情况。

要点是你应该知道你的O / RM工作（并希望有测试），所以没有理由测试基本的CRUD行为。

您肯定需要一个“测试平台” - 内存数据库，可以检入源代码管理的本地文件支持的数据库，或者（如果必须）共享数据库。一些测试框架提供了回滚功能来恢复数据库状态;如果您在同一测试中遇到多个数据库，或者（如果您有嵌入式事务），则要小心。

编辑：请注意，这些集成测试仍将在“隔离”中测试您的存储库（除了数据库）。您的所有其他单元测试都将使用虚假存储库。

Answer 4

我最近提到了一个非常相似的问题over here。

总结：如果这样做有价值，请测试具体的Repository实现。如果您在实现中执行了一些复杂的操作，那么测试它可能是个好主意。如果您使用的是没有自定义逻辑的ORM，那么在该级别编写测试可能没什么价值。