子类的单元测试

Question

假设我们有一个超级简单的类层次结构：

public class SomeMath
{
    public int Add(int x, int y)
    {
        return x + y;
    }
}

public class MoreMath : SomeMath
{
    public int Subtract(int x, int y)
    {
        return x - y;
    }
}

当我为 MoreMath 类编写测试时，我应该为 Add 方法编写测试吗？或者我应该只在测试 SomeMath 类时关心该方法？更一般地说：我应该测试一个类的所有方法，还是应该只测试“新”方法？

我可以为双方找出一些理由。例如，当测试所有方法时，您最终将多次测试同一事物，这不太好并且可能变得乏味。但如果您不测试所有方法，SomeMath 中的更改可能会破坏 MoreMath 的使用？这也是一件坏事。我想这也可能取决于具体情况。就像它是否扩展了我是否可以控制的类一样。但无论如何，我是一个完全的测试新手，所以我很想知道哪些人比我认为的更聪明:-)

Answer 1

我只会测试 SomeMath 类的 Add 方法。如果 MoreMath 仅仅继承它并且绝对不做任何新的事情，那么为两者编写测试将是纯粹的重复代码，仅此而已。恕我直言，对这些事情保持务实一点总是好的。

Answer 2

首先，我认为至少有两个因素可能会影响您做出其中一项决定：

• 继承的目的是什么？
• 有关测试的目的是什么？

在 TDD 场景中，我倾向于为 MoreMath 编写一个测试用例来验证它是否派生自 SomeMath，然后考虑覆盖从 SomeMath 继承的所有成员。

然而，这意味着，从设计的角度来看，MoreMath 源自 SomeMath，这是一个重要的设计方面。如果您以多态方式使用 SomeMath，情况肯定会如此。但是，如果您只是使用继承来重用（但不推荐），情况就不会如此。

在后一种情况下（继承是为了重用），父类和子类之间没有概念上的联系，你将来可能会想要破坏继承。在这种情况下，进行测试来验证父母的正确性是一个很差的保障措施。

从质量保证（QA）的角度来看，每个班级的每个成员都应该经过严格的测试。这意味着即使测试代码相同，您也应该为每个子类重复测试代码，因为您需要验证没有虚拟方法以意外的方式被重写。但是，为了保持干燥，您可以将它们编写为参数化测试，或者使用诸如 Pex。

就我个人而言，我很少进入质量检查阶段。通常，在 TDD 期间创建的测试套件是一个足够的安全网……但这一切都取决于您构建的软件类型。

Answer 3

在我现在的地方，我们遇到了一个类似的问题，我们想要开发接口，但要确保接口的每个实现都行为正确（例如，无论该层的实现如何，不同的数据层都应该表现相同）。我们解决这个问题的方法（使用 NUnit）是在单元测试中拥有一个继承结构：

public interface ICalculator
{
  public int Add(int a, int b)
}

public class Calculator : ICalculator
{
  public int Add(int a, int b) { return a + b; }
}

public class TestCalculatorInterface
{
   public abstract SomeMath GetObjectToTest();

   [Test]
   public void TestAdd()
   {
       var someMath = GetObjectToTest();
       ...
   }
}    

[TestFixture]
public class TestCalculator: TestCalculatorInterface
{
   public virtual Calculator GetObjectToTest() { return new Calculator(); }
}

我们在基本接口测试上不会有 [TestFixture] 属性，但会有 [Test] 所有测试方法的属性。 TestCalculator 类是 [TestFixture]，但从基类继承了所有测试，这使得子类仅负责提供用于测试该接口的对象。

我会针对您的情况采用类似的模式，因此测试针对所有类运行，但只编写一次。

Answer 4

我将使 MoreMath 的测试类继承 SomeMath 的测试类，从而继承该类的所有测试。这意味着我只需为新功能编写额外的测试，但所有子类的功能都经过充分测试。

Answer 5

通常我不会测试子类中的行为，除非子类改变了父类中预期的行为。如果它使用相同的行为，则无需测试它。如果您计划对父类进行重大更改，但子类仍然需要旧的行为，那么我将首先在子类中创建测试来定义其所需的行为，然后我将在父类测试和后续测试中进行更改代码更改。这遵循 YAGNI 原则——你不会需要它——并延迟子测试的实施，直到它们真正有目的为止。