是否有必要为 n 层架构上的每一层编写单元测试代码?
Posted
技术标签:
【中文标题】是否有必要为 n 层架构上的每一层编写单元测试代码?【英文标题】:Is it necessary to code unit tests for every single layer on an n-tier architecture? 【发布时间】:2015-11-02 15:44:32 【问题描述】:我是单元测试的新手,所以我一直在尝试编写一些示例来学习使用它们的正确方法。我有一个使用实体框架连接到数据库的示例项目。
我正在使用由一个使用 EF 查询数据库的数据访问层、一个调用数据访问层方法来查询数据库并使用检索到的数据执行其业务目的的业务层和一个服务层组成的 n 层架构它由简单地调用业务层对象的 WCF 服务组成。
我是否必须为每一层(数据访问、业务层、服务层)编写单元测试代码?
为查询数据库的方法编写单元测试的正确方法是什么?下一个代码是我的数据访问层中对数据库执行选择的方法的示例,它的单元测试应该如何?
public class DLEmployee
private string _strErrorMessage = string.Empty;
private bool _blnResult = true;
public string strErrorMessage
get
return _strErrorMessage;
public bool blnResult
get
return _blnResult;
public Employee GetEmployee(int pintId)
Employee employee = null;
_blnResult = true;
_strErrorMessage = string.Empty;
try
using (var context = new AdventureWorks2012Entities())
employee = context.Employees.Where(e => e.BusinessEntityID == pintId).FirstOrDefault();
catch (Exception ex)
_strErrorMessage = ex.Message;
_blnResult = false;
return employee;
【问题讨论】:
您将从模拟框架开始选择权衡取舍。其他人将设置以某种方式恢复的测试数据库或使用在拆除时回滚的事务。见这里***.com/questions/22690877/… 感谢您的链接,带我去看了单元测试时模拟实体框架的精彩教程asp.net/web-api/overview/testing-and-debugging/… 【参考方案1】:这是我基于领域驱动设计原则的 2 美分:
您的业务层不应依赖于具体的数据层,而应仅定义数据层可以实现的一些抽象接口(存储库)。 您绝对应该使用不接触文件系统的假数据层单元测试您的业务层。 您可能会创建集成测试,包括您的服务和带有虚假数据层的业务层。模拟业务层并检查业务层上的服务层调用是没有意义的(行为测试),而是检查它对通过业务层可观察到的业务对象所做的状态更改. 您应该使用真实的数据层、服务和业务层创建一些端到端测试,并在服务层上练习一些用例。如果您刚开始进行单元测试,我建议您阅读 Kent Beck 的 Test Driven Development by Example 和 Gerard Meszaros 的 xUnit Test Patterns
【讨论】:
+1 好答案。我同意你的观点,对所有层进行单元测试是没有意义的,但你肯定需要对业务层进行全面测试。虽然我会添加只模拟与业务层的外部通信,而不是模拟业务层内的每一层。【参考方案2】:我不得不说是的,有必要对每一层进行单元测试。这样做将提供更好的覆盖范围。它的维护部分可能具有挑战性,因为您最终会得到很多单元测试用例,但是当有人试图破坏一些非常重要的逻辑时,它确实有助于避免巨大的陷阱。最好使用 Jenkins 等持续集成工具自动化所有层的单元测试。
至于您在数据库层进行单元测试的示例,请像您所拥有的一样保持简单,并根据元数据(例如必填字段、单元格数据的大小等)进行断言。
【讨论】:
以上是关于是否有必要为 n 层架构上的每一层编写单元测试代码?的主要内容,如果未能解决你的问题,请参考以下文章