布置单元测试——嵌套类还是完全隔离？

Question

我有一个类，我已经抽象出来，可以测试并开始遇到一个有趣的困境。这些测试类应该嵌套吗？例如 ...

public class ValidateCompanyTests
{
     public virtual Setup()
     {
          //setup stuff
     }

     [TestClass]
     public class AndCompanyDoesNotExist : ValidateCompanyTests
     {
          public override Setup()
          {
               base.Setup();
               //setup specific condition
          }

          [TestMethod]
          public void ShouldReturnFalse()
          {

          }

          [TestMethod]
          public void ShouldCreateError()
          {

          }

          [TestMethod]
          public void ShouldSaveError()
          {

          }
     }
}

AndCompanyDoesExist 的设置几乎相同，但条件更多。

我的问题是，除了只在 MSTest 中打印出来的明显方法之外，我不确定这是否是一种“更正确”的方法，或者我应该完全隔离每个测试。会有很多重复的代码（设置、配置），所以这就是导致我做出这个决定的原因，但我想要一些社区的意见、想法和想法。

所以把它放在我身上！（这也应该是社区维基？？）

Answer 1

我过去用这种方法遇到的问题是它看似简单……起初。嵌套上下文很好，直到您达到第二级继承。突然之间，除非您深入了解 3 个层次结构，并记下大量笔记、绘制地图、施放符文等，否则您将无法追踪您的测试所处的世界。

我赞成一种方法，在这种方法中，设置上下文的机制由测试本身明确指导。每个测试类代表一个单独的上下文，它可以自行设置，或者通过利用一组外部帮助程序来创建所需的对象。通过这种方式，我总是能够查看测试初始化​​方法，并至少看到对该类中测试的“世界”是什么样子的高级描述。

让“助手”尽可能地相互利用，但测试设置本身应该类似于以下伪代码： Given_a_valid_Customer() .WithValidOrders(2) .WithInvalidOrders(1);

Given_a_valid_Customer 应设置客户和任何必需的子对象，如地址。.WithValidOrders(2) 添加两个有效订单，包括所需的任何子对象，如 LineItems。最后，.WithInvalidOrders 添加了一个带有一些致命缺陷的订单。

关键是设置没有陷入细节。什么使订单有效或无效？谁在乎，这不是这个测试的目的。这个测试只关心在几个有效的订单中是否有一个无效的订单，这是这里唯一重要的细节。无效订单的定义可以在别处定义，然后由多个测试上下文利用。如果稍后有关该定义的某些内容发生更改，则可以在那个辅助方法中“修正”它，而不是在数百个单独的测试中。

当我查看这个测试时，我知道它的世界在我关心的细节水平上是什么样子。

Answer 2

如果您的目标是最大限度地减少重复设置代码的数量，我将使用内部类的继承。继承还将为您提供更多的重用灵活性，并使您的测试重构更加容易。