database - 单元测试数据库

Question

去年夏天，我正在开发一个基本的 ASP.NET/SQL Server CRUD 应用程序，单元测试是其中一项要求。当我试图针对数据库进行测试时遇到了一些麻烦。据我了解，单元测试应该是:

• 无国籍
• 相互独立
• 可重复获得相同的结果，即没有持久的变化

在为数据库开发时，这些要求似乎相互矛盾。例如，如果不确保要插入的行还不存在，我就无法测试 Insert()，因此我需要先调用 Delete()。但是，如果它们还不存在怎么办？然后我需要先调用 Exists() 函数。

我最终的解决方案涉及非常大的设置函数(糟糕!)和一个空的测试用例，它将首先运行并指示设置运行没有问题。这是在牺牲测试的独立性的同时保持它们的无状态。

我发现的另一个解决方案是将函数调用包装在一个可以轻松回滚的事务中，例如 Roy Osherove's XtUnit .这项工作可行，但它涉及另一个库、另一个依赖项，而且对于手头的问题来说，它似乎有点太重了。

那么，面对这种情况，SO 社区做了什么？

---

tgmdbm 说:

You typically use your favourite automated unit testing framework to perform integration tests, which is why some people get confused, but they don't follow the same rules. You are allowed to involve the concrete implementation of many of your classes (because they've been unit tested). You are testing how your concrete classes interact with each other and with the database.

因此，如果我没看错的话，确实没有办法有效对数据访问层进行单元测试。或者，数据访问层的“单元测试”是否会涉及测试类生成的 SQL/命令，而不依赖于与数据库的实际交互？

Answer 1

除了断言表存在、包含预期的列并具有适当的约束之外，没有真正的方法可以对数据库进行单元测试。但这通常并不值得这样做。

您通常不会对数据库进行单元测试。您通常会在集成 测试中涉及数据库。

您通常使用自己喜欢的自动化单元测试框架来执行集成测试，这就是为什么有些人会感到困惑，但他们不遵循相同的规则。您可以参与许多类的具体实现(因为它们已经过单元测试)。您正在测试您的具体类如何相互交互以及如何与数据库交互。