是否有必要为n层架构上的每个单独的代码进行代码测试?

时间:2015-08-10 16:16:17

标签: c# entity-framework wcf unit-testing

我是单元测试的新手,所以我一直在尝试编写一些示例来学习使用它们的正确方法。我有一个示例项目,它使用Entity Framework连接到数据库。

我使用由数据访问层组成的n层体系结构,该数据访问层使用EF查询数据库,业务层调用数据访问层方法查询数据库并使用检索到的数据执行其业务目的服务层,由简单调用业务层对象的WCF服务组成。

我是否必须为每一层(数据访问,业务层,服务层?

)编写单元测试代码

哪种方法可以为查询数据库的方法编写单元测试代码?下一个代码是我的数据访问层中的一个方法示例,它对数据库执行select,它的单元测试应该如何?

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;
    }

2 个答案:

答案 0 :(得分:8)

以下是基于领域驱动设计原则的2美分:

  • 您的业务层不应该依赖于具体的数据层,它应该只定义数据层可以实现的一些抽象接口(存储库)。
  • 您绝对应该使用不接触文件系统的虚假数据层单元测试您的业务层。
  • 您可以创建集成测试,包括具有虚假数据层的服务业务层。没有必要嘲笑业务层并检查业务层上的服务层调用(行为测试),而是检查它对通过业务层可观察的业务对象所做的状态更改
  • 您应该使用真实数据层,服务和业务层创建一些端到端测试,并在服务层上运用一些用例。

如果您刚开始进行单元测试,我建议您阅读Kent Beck的Test Driven Development by Example和Gerard Meszaros xUnit Test Patterns

答案 1 :(得分:1)

我不得不说是有必要对每一层进行单元测试。通过这样做将提供更好的覆盖范围。它的维护部分可能具有挑战性,因为你最终会得到大量的单元测试用例,但是当有人试图打破一些非常重要的逻辑时,它确实有助于避免巨大的陷阱。最好使用Jenkins等连续集成工具自动对所有层进行单元测试。

至于您在单元测试的数据库层上的示例,请保持简单,就像您拥有的那样,并根据元数据(如必填字段,单元格数据大小等)进行断言。