为什么不在单元测试中访问数据库呢?

你只是处于语义灰色地带。

• 系统测试从端到端覆盖整个系统。
• 单元测试可用于描述端到端循环的一个子段。

web应用程序的一种常见方法是编写一系列测试数据访问层的单元测试。..

然后编写一系列单元测试来测试应用层(包括数据层)。..

最后编写一些基于浏览器的系统测试。..

但有时(正如我目前在写这篇文章时所做的那样),你必须查看数据库,以制作一个有意义和健壮的测试套件(我正在测试服务器-服务器传输协议)。

• 你希望你的测试尽快进行

在您的情况下,您需要测试存储过程。然后,您需要编写一个运行这些存储过程的测试。您可以通过代码运行它们(集成测试),也可以直接从测试中运行它们(类似于单元测试)。在这两种情况下,你都可以使用Nunit。

好吧,问题是,如果你让你的单元测试访问数据库,你不仅仅是在测试单个代码单元,而是在测试几个单元——还有DAL、存储过程等。这就是为什么TDD的支持者说不要在单元测试中访问数据库。

这也是为什么你不应该过于重视纯粹的、TDD概念化的、理论上的神圣 U 尼特 实际测试系统 .
所谓的“组件测试”——更像是系统测试,但只针对系统的一小部分,端到端——在我看来是一个很好的折衷方案。

(现在提示TDD反驳…:)

写后 Should one test internal implementation, or only test public behaviour? 在讨论人们的答案时,我认为答案可能取决于开发团队中有多少人。

使用数据库进行测试的优点:

• 测试更现实(使用实际数据库)

使用数据库进行测试的缺点:

• 在写入数据库访问层之前,您的测试无法运行
• 如果出现错误或测试失败,您不知道错误是在代码中还是在数据库访问层

YMHO这里有点语义问题和技术问题。

单元测试应该单独测试一小部分代码,以便在没有其他代码的情况下对其进行检查。失败的单元测试应该意味着只有一小部分代码需要检查和纠正(通常是实现功能的代码和单元测试本身)。

其他测试范围包括检查整个系统的功能(系统测试),或验证完整功能的功能测试,或检查交互的集成测试,检查是否存在已纠正测试的回归测试等。

必须为每个项目设计一个测试策略,但一般来说,有不同的类别会有很大帮助。因此,单元测试应仅限于测试尽可能小的单元 单位

要使用单元测试库执行一些功能测试,我想如果你将你的套件与严格的单元测试和功能测试分开(即使它们共享测试工具),这也没什么大不了的

在测试中处理数据库的问题是,数据库中的更改或代码中的更改可能会使测试失败。单元测试通常应该尽可能直接地指向导致他失败的变化。 在我参与的一个项目中,我们创建了一个小型数据库,在每次测试之前将其生成到内存中。

“…单元测试运行时不应访问数据库…”-当然,除非您是单元测试持久性对象。

我不知道你引用了哪些博客,但我敢打赌,他们说的是,在集成测试期间嘲笑一些组件可能会有好处。如果您已经对持久层进行了单元测试,则无需再次测试。在这种情况下,嘲笑的好处更多地与减少依赖性和不确定性有关。例如,您可能已经对代码进行了单元测试,将其打包,现在是时候将其移动到更接近生产的环境中了。如果您需要的数据库不可用(例如,没有正确的模式版本,缺少您需要的数据,或者只是先到达那里的另一个应用程序需要的数据),您可以使用模拟来允许您的集成测试毫不拖延地进行。