单元测试业务逻辑层

Posted 2023-02-24

【中文标题】单元测试业务逻辑层

【英文标题】：Unit test business logic layer

【发布时间】：2012-02-05 06:55:00

【问题描述】：

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

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

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

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

非常感谢您的努力！

马可

【参考方案1】：

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

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

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

【讨论】：

嗨安德烈斯！这就是我要说的……我开始编写直接与开发数据库接口的测试，一切似乎都是正确的，但是阅读这本书后，我开始相信这不是正确的做法……所以你准备更多的测试和我一样吗？

【参考方案2】：

是的，

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

你说得对。

我建议你：

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

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

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

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

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

【讨论】：

嗨 w0lf！谢谢你的时间。这就是我想做的，但我正在寻求确认。我写了 20 种测试方法，运行整个测试用例至少需要 10-15 秒。我认为它太多了，但我真的无法理解如何有效地模拟我的 EntityFramework 模型。会发现一些东西。顺便说一句，我在看书，这就是为什么我开始怀疑了！！！

我没有使用过实体框架，但你可以看看 Repository Pattern 并搜索“Entity Framework Repository”。或者，您可以将负责与数据库对话的组件包装在抽象后面，并将其用作 seam 来注入虚假实现。