单元测试业务逻辑层

Question

我开始在我们公司引入正式的单元测试，因为我们有一个越来越大的项目，在这个项目上，另一个人将会帮助我。所以我需要确保他的所作所为不会破坏一切，反之亦然。

我也想介绍一个CI服务器，但这将是其他问题的主题。现在的问题是:我目前正在阅读“单元测试的艺术”(这是一个推荐的杰作！)作者强调的是，单元测试不同于集成测试。这对我来说很清楚，如果我理解得很好，业务逻辑单元测试应该避免依赖于数据库连接等。首先:我说的对吗？

那么，假设我是对的(例如，当我单元测试我的BLL时，我应该存根数据库)，我该怎么做呢？我读到有一些db mocking框架。我应该使用其中的一个吗？你用哪一种？

下一个问题:你真的认为这是一个正确的方法吗？我的意思是:在我的项目中，BL通过实体框架与数据库交互。因此，例如，当我的BLL中的方法"UpdateItem“被调用时，它会执行一些操作，然后保存ObjectContext。这个ObjectContext是我需要在BL中删除的实体框架依赖项。但是我应该在这种方法中测试什么呢？如果不一起测试DAL，我真的不能理解单元测试BL层……你能给我举一些例子吗？

非常感谢您的努力！

马可

Answer 1

是,

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

关于这一点，你是对的。

我建议您：

• 对业务层使用一套单元测试，使用存根而不是真正的DB调用。您可以使用最适合您的任何方式(您拥有伪类或模拟库)来存根DB，前提是您在DB components.
• use上有一套集成测试来测试实际的DB调用(仅此而已！)

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

我认为这很好，因为它允许您在更改代码时非常频繁地运行业务单元测试。这一点很重要，因为你会得到非常快的反馈(通常在1-2秒内)，你所做的更改没有破坏任何东西。

偶尔，您可以运行集成测试(这将需要更长的时间)来验证DB是否仍然正常工作。

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

Answer 2

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

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

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