单元测试业务逻辑层

Question

我开始在我们公司引入正规单元测试，因为我们正在开发一个越来越大的项目，在这个项目中，另一个人会帮助我。因此，我需要确保他所做的并不会分解，反之亦然。

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

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

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

非常感谢您的努力！

马

Answer 1

是，

  

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

你是对的。

我建议你：

• 使用一组单元测试用于业务层，使用存根而不是真正的DB调用。您可以使用最适合您的数据（您拥有虚假类或模拟库）来存储数据库，前提是您有数据库组件的抽象。
• 使用一套Integration测试来测试实际的DB调用（仅限于！）

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

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

偶尔，您可以运行集成测试（需要更长时间）来验证数据库是否仍能正常运行。

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

Answer 2

对数据库进行存储是一项艰巨的任务，我认为这不值得。我更喜欢有一个特殊的数据库副本，其中精心准备的数据适合于单元测试。

测试可以在测试结束时回滚的事务中运行。这样，单元测试数据库永远不会被测试修改，并始终保持已知状态。

我在博客上的Using Transactions for Unit Tests写了这篇文章。示例代码用于linq-to-sql，但同样的方法也适用于实体框架。