如何对持久性进行单元测试？

Question

作为实践测试驱动开发的新手，我经常陷入困境，即如何对数据库的持久性进行单元测试。

我知道从技术上讲这将是一个集成测试（而不是单元测试），但我想找出以下方面的最佳策略：

1. 测试查询。
2. 测试插入。 如果插入失败，我怎么知道它出错了？ 我可以通过插入然后查询来测试它，但是我怎么知道查询没有错呢？
3. 测试更新和删除——与测试插入相同

执行这些操作的最佳做​​法是什么？

---

关于测试 SQL：我知道这可以完成，但是如果我使用像 NHibernate 这样的 O/R 映射器，它会在用于输出查询的别名中附加一些命名疣，因为这有点不可预测，我不确定我可以测试一下。

我应该放弃一切并简单地信任 NHibernate 吗？ 我不确定这是否谨慎。

Answer 1

查看 DB 单元。 它是一个 Java 库，但必须有一个 C# 等效项。 它可以让您使用一组数据准备数据库，以便您知道数据库中的内容，然后您可以与 DB Unit 交互以查看数据库中的内容。 它可以在许多数据库系统上运行，因此您可以使用实际的数据库设置，或使用其他东西，例如 Java 中的 HSQL（具有内存选项的 Java 数据库实现）。

如果您想测试您的代码是否正确使用了数据库（您很可能应该这样做），那么这是隔离每个测试并确保数据库已准备好预期数据的方法。

Answer 2

正如Mike Stone 所说，DbUnit 非常适合在运行测试之前让数据库进入已知状态。 测试完成后，DbUnit 可以将数据库恢复到运行测试之前的状态。

数据库单元 (Java)

数据库单元.NET

Answer 3

您可以通过模拟数据库连接来进行单元测试。 通过这种方式，您可以构建方法调用流中的特定查询成功或失败的场景。 我通常构建我的模拟期望，以便忽略实际的查询文本，因为我真的想测试方法的容错能力以及它如何处理自己——SQL 的细节与此无关。

显然这意味着您的测试实际上不会验证该方法是否有效，因为 SQL 可能是错误的。 这是集成测试开始的地方。为此，我希望其他人会有更彻底的答案，因为我自己才刚刚开始掌握这些。

Answer 4

我在这里写了一篇关于单元测试数据层的帖子，其中涵盖了这个确切的问题。 为（可耻的）插件道歉，但文章太长，无法在此处发布。

我希望对您有所帮助 - 在过去的 6 个月中，它在 3 个活动项目上对我来说效果很好。

问候，

罗布

Answer 5

我在单元测试持久性时遇到的问题，尤其是没有 ORM 从而模拟您的数据库（连接）时，您并不真正知道您的查询是否成功。 可能是您的查询是专门为特定数据库版本设计的，并且只能在该版本上成功。 如果你模拟你的数据库，你永远不会发现这一点。 所以在我看来，单元测试持久性的用途有限。 您应该始终添加针对目标数据库运行的测试。

Answer 6

对于NHibernate ，我绝对提倡为单元测试NHibernate API —— 相信库会做正确的事情。 如果要确保数据确实进入数据库，请进行集成测试。

Answer 7

对于基于 JDBC 的项目，可以使用我的 Acolyte 框架： http : //acolyte.eu.org 。 它允许模拟您想要测试的数据访问，受益于 JDBC 抽象，而无需管理特定的测试数据库。

Answer 8

我还会模拟数据库，并检查查询是否符合您的预期。 存在测试检查错误 sql 的风险，但这会在集成测试中检测到

Answer 9

从技术上讲，持久性的单元测试不是单元测试。 它们是集成测试。

在 C# 中使用 mbUnit，您只需使用SqlRestoreInfo和RollBack属性：

    [TestFixture]
    [SqlRestoreInfo(<connectionsting>, <name>,<backupLocation>]
    public class Tests
    {
      
        [SetUp]
        public void Setup()
        {
        
        }

        [Test]
        [RollBack]
        public void TEST()
        {
           //test insert. 
        }
    }

在 NUnit 中也可以这样做，只是属性名称略有不同。

至于检查，如果您的查询成功，您通常需要使用第二个查询来查看数据库是否已按您的预期更改。

Answer 10

我通常创建一个存储库，用它来保存我的实体并检索一个新的实体。 然后我断言检索到的等于保存的。