在一个用于执行测试的类和一个用于安装的类中构造单元测试是否明智？

Question

最近，当为类编写单元测试时(特别是在使用DI和mocks时)，我发现将测试构造为一个实际运行测试的类和一个负责设置的类非常方便，这有助于我保持测试的整洁和可读性。

测试类如下所示

public class MyFooBarTests
{
    MyFooBarTestFixture _testFixture = new MyFooBarTestFixture();

    [SetUp]
    public void SetUp()
    {
        _testFixture.SetUp();
    }

    [Test]
    public void ATest()
    {
        _testFixture.GivenRepositoryReturnsPi();
        _testFixture.CallMyFancyMethod();
        _testFixture.AssertQuxBaxIs(3.14159);
    }
}

我称之为测试夹具的样子是这样的

internal class MyFooBarTestFixture
{
    private Mock<IRepository> _repositoryMock;
    private MyFooBar _cut;

    public void SetUp()
    {
        SetUpRepositoryMock(); // elided
        SetUpCut();
    }

    private void SetUpCut()
    {
        _cut = new MyFooBar(_repositoryMock.Object);
    }

    public void GivenRepositoryReturnsPi()
    {
        _repositoryMock.Setup(r => r.GetValue()).Returns(Math.PI);
    }

    public void CallMyFancyMethod()
    {
        _cut.MyFancyMethod();
    }

    public void AssertQuxBaxIsEqual(double expectedValue)
    {
        Assert.That(_cut.QuxBaz, Is.EqualTo(expectedValue)); // elided correct floating point comparison
    }
}

在我看来，这种分离是很有帮助的。当查看测试类时，测试正在做什么是非常清楚的，而如何完成测试的细节则隐藏在测试夹具中，并被整齐地封装在测试夹具中。测试夹具又有简洁、简洁的方法。

像这样组织我的单元测试有什么缺点？

一些想法：

• 我知道有些测试需要在这种模式下进行特殊处理。
• 当有相当多的模拟时，测试夹具将失去内聚力，但这可能是一个提示，即测试中的组件无论如何都会产生很大影响。
• 这种模式的出现是否表明我的课程已经在做很多事情了？
• 测试夹具的名称可能有误导性吗？从技术角度看，这是明智的，因为在其他工程领域，测试夹具是为运行测试而设置的，但不一定要运行测试本身。无论如何，在软件开发中，这个术语可能会提高我所谓的测试夹具无法满足的期望。

Answer 1

这是一个很好的范例，而且“是的”--你的名字是误导人的。它实际上是一个试验帮手。它不仅在设置中很有用，而且在验证方面也是有益的(一般来说，Assert.cs中的NUnit符合这种模式)。

好处不限于使您的测试代码更具可读性(对测试作为文件有好处)。它还使您能够针对这些帮助方法编写测试。因此，实现了缺陷定位。

根据缺点，我找不到具体的缺点。我唯一能看到的是，在获得了这样的帮助之后，您可能希望在不同的测试用例中使用它们。这就是事情变得一团糟的地方。如果你不仔细组织它们，这些帮手很容易变胖。然后

更多xunit模式，签出xUnit测试模式:重构测试代码

Answer 2

根据您的语言，这不是分离这类代码的唯一方法。在.NET中，有一个可以实现的部分类的概念。还有一些代码区域，但这些代码区域正逐渐失去对有很多原因的青睐。

在个人POV中，我倾向于等到设置的对象需要在另一组测试中重用(在将它们放入单独的类( YMMV )之前考虑：三条规则 )。

请注意，没有逻辑的类是已知的代码气味。确保helper类实际上正在执行某些操作，而不仅仅是一系列属性。

阻止测试类变得难以处理的一个很好的经验规则是确保它们反映底层类。这样做的一个好处是，您可以一眼看到哪些类仍然需要测试。当然，一个巨大的类可以产生一个大型的测试类，但是这些应该是非常例外的。