单元测试业务逻辑层

Question

我开始在我们公司介绍形式单元测试，因为我们有一个越来越大的项目，在这个项目上另一个人会帮助我。所以我需要确定他所做的事情并没有打破所有方面，反之亦然。

我也想介绍一个CI服务器，但这将是其他问题的主题。现在的问题是：我正在阅读“单元测试的艺术”（这是一个建议的杰作！），作者强调的是单元测试与集成测试不同。对我来说这很明显，如果我理解的很好，Business Logic单元测试应避免依赖数据库连接等。首先：我是对的吗？

所以，假设我是正确的（即当我单元测试我的BLL时，我应该存根数据库），我该怎么做呢？我读过，有一些数据库嘲笑的框架。我应该使用其中之一吗？你使用哪个？

下一个问题：你真的认为这是一个正确的方法吗？我的意思是：在我的项目中，BL通过实体框架与数据库连接。所以，例如，当我的BLL中的方法“UpdateItem”被调用时，它会执行一些操作，然后保存ObjectContext。这个ObjectContext是我需要在我的BL中删除的实体框架依赖项。但是，我应该如何测试这种方法？我真的无法理解没有测试DAL的单元测试BL层......你能举个例子吗？

非常感谢您的努力！

马尔科

Answer 1

打桩数据库是一项艰巨的任务，我不觉得是值得的。我更喜欢有一个特殊的数据库副本，以及适合单元测试的仔细准备的数据。

测试可以在测试结束时回退的事务中运行。这样，单元测试数据库永远不会被测试修改，并始终保持已知状态。我的博客上写到Using Transactions for Unit Tests。这里的示例代码是针对linq-to-sql的，但同样的方法也适用于实体框架。

Answer 2

是，

业务逻辑的单元测试应避免依赖于数据库

你是对的。

我建议你：

• 使用一套单元测试业务层，使用存根的，而不是真正的数据库调用。您可以用任何最适合您的数据库（您拥有虚拟类或模拟库）来存储数据库，前提是您已对数据库组件进行了抽象。
• 使用一套集成的测试来测试实际的数据库调用

单元测试和集成测试之间的主要区别是（也是唯一的！）： *单元测试的速度快，不需要任何配置 *集成测试可能很慢并且需要正确的配置（应该设置一个数据库，并且应该有一个指向它的适当的连接字符串）。

我认为这很好，因为它允许您在更改代码时经常运行业务单元测试。这一点很重要，因为您得到的反馈速度非常快（通常在1-2秒内），所做的更改不会破坏任何内容。

偶尔，您可以运行集成测试（这将花费更长的时间）来验证数据库仍能正常工作。

此外，我建议你阅读你提到的书。它认为这是有关该主题的非常重要的信息来源。