单元测试领域模型对象答案

【问题标题】：Unit testing Domain model objects单元测试领域模型对象
【发布时间】：2010-03-02 11:03:24
【问题描述】：

在我们的核心域模型设计中，我们有一个名为“Category”的类，其构造函数是内部设计的。由于构造函数是内部的，因此在编写单元测试用例时，我将无法创建“类别”的对象。

所以我的问题是，将构造函数公开只是为了使“类别”类可测试是最佳实践吗？或者我不应该测试那个“类别”，而是应该测试负责创建这个对象的类/方法？

塔，

拉吉什

【问题讨论】：

我正在使用 C#。我在“InternalsVisibleToAttribute”中看到的问题是我们将 TestCase 链接到实际代码。
我建议改写标题，以反映问题是关于使用私有/内部构造函数的类的单元测试。

标签： c# unit-testing tdd domain-driven-design

【解决方案1】：

不要仅仅为了单元测试而公开构造函数。如果您从设计角度决定它应该是内部的，那就这样吧。测试调用此构造函数的类。

在 .NET 中，InternalsVisibleToAttribute 允许您将内部成员公开给单元测试。

【讨论】：

【解决方案2】：

TDD 意味着 Test-Driven 设计，由此推论，如果您无法测试构造函数，它就不能真正是内部的“设计”。

考虑为什么它是内部的。这将告诉您如何解决该问题。您不应该将构造函数公开只是为了能够对其进行测试，但您应该考虑一种易于创建新实例的设计。

通常，构造函数是内部的以保护不变量，但您也可以使用将所需输入作为构造函数参数的公共构造函数来实现相同的目标。

public class MyClass
{
    private readonly string requiredString;

    public MyClass(string requiredString)
    {
        if (requiredString == null)
        {
            throw new ArgumentNullException("requiredString");
        }
        this.requiredString = requiredString;
    }
}

注意 Guard 子句和 readonly 关键字的组合如何保护类的不变量。这通常是内部构造函数的一个很好的替代方案。

使用内部构造函数的另一个原因是当你有一个可能返回多态对象的工厂方法时，但再次考虑如果它不公开构造函数是否会有问题均值妥协不变量。

TDD 的美妙之处在于它迫使我们仔细审视任何设计决策，并能够真正证明每一个决策。考虑将构造函数设为内部然后修改 API 以便于创建类型的合理性。

【讨论】：

【解决方案3】：

添加

 [assembly: InternalsVisibleTo("UnitTestAssembly")]

到您的 AssemblyInfo.cs。然后UnitTestAssembl.dll 可以调用你的内部方法。更多信息可通过here 获取。

【讨论】：

【解决方案4】：

您可以考虑创建一个名为

的静态工厂方法

Category *ConstructCategory_ForUnitTest();

你可以用它来创建对象只是为了测试它。

从名称中可以看出它不应该在测试环境之外使用，代码审查可以很容易地发现生产级代码中的“非法”使用。

【讨论】：