【问题标题】:TDD inject Mocked Repository(UnitOfWork) into internal constructorTDD 将 Mocked Repository(UnitOfWork) 注入内部构造函数
【发布时间】:2011-08-09 15:44:34
【问题描述】:

我正在研究 TDD,我遇到了一个可以使用一些帮助的场景。

我的项目使用 MVC3,并且结构具有 BAL 和 DAL 层。每一层都在自己的项目中。 BAL 通过存储库模式访问数据库。由于我使用的是 EntityFramework,因此我还实现了 UnitOfWork 模式。 BAL 中的服务类如下所示:

public class ExampleService
{
    private UnitOfWork unitOfWork;
    private bool isProcessing = false;

    internal ExampleService(UnitOfWork unitOfWork)
    {
        this.unitOfWork = unitOfWork;
    }
    public void ExposedMethod()
    {
        //do stuff with the unitOfWork
    }
}

问题:我想为此创建一个单元测试(显然我应该在代码之前编写测试)。但是,如果我按原样运行代码,测试将是一个集成测试,因为它将使用 UnitOfWork 并连接到我的数据库。我可以模拟一个新的 UnitOfWork 访问内存中的虚拟数据,但我不明白如何注入它,因为构造函数是内部的。我宁愿不编写驻留在每个项目中的单元测试。

有什么想法吗?

【问题讨论】:

    标签: asp.net-mvc-3 tdd repository


    【解决方案1】:

    您可以使用[InternalsVisibleTo] 属性装饰包含此类的程序集,以使所有内部成员在单元测试项目中可见。

    另一种可能性是将这个构造函数公开,因为这会使类更可重用。通常,DI 连接应该在架构的最外层 (GUI) 中完成,因此不同依赖项的构造函数需要是公共的。这允许在其他项目中重用此 DAL 层。

    【讨论】:

    • [InternalsVisibleTo] 将按原样解决我的问题。我可能仍然缺少 DI 的某些内容,但我展示的示例类在 BAL 中,UnitOfWork 在 DAL 中。我将构造函数标记为内部,因为我有另一个控制对示例类的访问的类。我将不得不更多地考虑这一点。谢谢!
    猜你喜欢
    • 2018-03-27
    • 2014-01-23
    • 1970-01-01
    • 2014-03-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-01-01
    • 1970-01-01
    相关资源
    最近更新 更多