1

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

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

所以，假设我是对的（即当我对我的 BLL 进行单元测试时，我应该存根数据库），我将如何做呢？我读过有一些用于数据库模拟的框架。我应该使用其中之一吗？你用哪个？

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

非常感谢您的努力！

马可

4

2 回答 2

4

是的，

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

你是对的。

我建议你：

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

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

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

偶尔，您可以运行集成测试（这将需要更长的时间）以验证数据库是否仍然正常工作。

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

于 2012-01-08T09:49:58.020 回答
0

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

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

我在我的博客上的使用事务进行单元测试中写到了它。那里的示例代码适用于 linq-to-sql，但同样的方法也适用于实体框架。

于 2012-01-08T09:40:44.253 回答