单元测试和数据库

Question

这个关于单元测试的问题 引发了另一件困扰我的事情。我反复研究了在访问数据库时进行单元测试的三种方法。

1. 创建模拟对象并将其插入。这样做的优点是不需要数据库，但它很耗时，而且我不确定我能获得多少投资回报。我已经了解了一些 IOC 和起订量，但看起来仍然很痛苦。
2. 创建安装和拆卸数据库脚本来创建已知案例并对其进行测试。同样，这可能会耗费大量时间，但大多数时候仍然比模拟对象更容易创建。假设其他工作人员的本地主机上有 SQL 服务器，他们仍然可以运行它。
3. 手动检查开发数据库并修改单元测试。密集的手动工作，但如果我有一个不改变的“测试集”，它似乎工作正常。至少在我的机器上:-)。

我知道选项 1 是进行单元测试的“正确”方法，但在这三个选项中，这可能是我使用最少的选项（尽管最新的项目已经与 IOC 合作，所以这扇门向我敞开）。我意识到这很大程度上取决于正在嘲笑的内容和正在测试的内容，但我在这里错过了什么？

如果上下文有帮助的话，我在一家 C# 商店中编写内部应用程序，只有几个开发人员。

Answer 1

如果您有一个仅公开少数 IQueryable 方法的数据访问层，那么第一个应该不会那么难。有一个很好的技巧可以用于伪造数据：只需将实体对象存储在 List 中并使用 AsQueryable。我发现这比数据部分的起订量更容易。

关于 IOC，我的立场是它目前被过度使用（请注意，我的观点代表了这方面的少数程序员）。您可以在测试过程中使用 Moles 之类的工具进行模拟，而不必滥用你的程序的设计。除非设计确实需要，否则我不会使用 IOC。

Answer 2

我肯定会继续使用真正的单元测试（选项 1）。我喜欢斯蒂芬对此的建议。

您可能还会发现与实际数据库的集成测试（选项 2）也必要（选项 2）。为什么？因为真正的单元测试并未涵盖您需要测试的部分内容（O/R 映射、与实际数据库模式的兼容性等）。

至于设置和拆卸逻辑，继承它通常就足够了（使用 .NET、NUnit 和 SqlServer 作为数据库）：

using System.Transactions;
using NUnit.Framework;
namespace Crown.Util.TestUtil
{
    [TestFixture]
    public class PersistenceTestFixture
    {
        public TransactionScope TxScope { get; private set; }

        [SetUp]
        public void SetUp()
        {
            TxScope = new TransactionScope();
        }

        [TearDown]
        public void TearDown()
        {
            if (TxScope != null)
            {
                TxScope.Dispose();
                TxScope = null;
            }
        }
    }
}

简单易行。

Answer 3

对此有一整套答案。要做的第一件事是清楚地阐明您正在测试的内容。它是一个 API 的外观，背后有一个数据库、DAO 对象、您的数据库结构吗？

做到这一点还将帮助您决定测试事物的最佳方法。据我所知，还有您列出的替代方案。也就是说，在内存数据库（例如 hsql）中启动，并针对该数据库运行类和测试。这意味着您可以在测试开始时创建数据库结构。因为它位于内存中，所以您不必担心拥有数据库服务器，它速度很快，并且您可以加载特定于测试的数据。

我经常使用模拟，虽然它们非常适合对类进行单元测试，但在某些情况下却并非如此。他们也很容易错过领先机会。与模拟一起工作的东西在集成时不起作用的情况并不罕见。原因是您正在加载带有某些期望和响应的模拟，您可能错误地从模拟所代表的事物中解释了这些期望和响应。

不要误会我的意思，我喜欢模拟并且经常使用它们。但这样做时，您绝不能假设因为某些东西经过了单元测试，所以它是正确的。它确实增加了机会，但在集成测试中实际上给你 100% 的保证。

Answer 4

你真正测试的是什么让你觉得这很困难？

如果将业务和服务层逻辑与持久性代码解耦，那么您应该能够轻松隔离想要进行单元测试的代码，而无需使用数据库。

单元测试最重要的原则之一是解耦和隔离测试。当您清楚地了解如何做到这一点时，单元测试就很容易了。如果不这样做，单元测试就会变得困难。