c# - 在 TDD 重构后编写更多单元测试

Question

这是我们反复讨论过的事情，人们对此的看法似乎差异很大。

基本问题，在进行 TDD 时，是否应该在周期的重构步骤之后添加额外的单元测试。我不是在谈论你的下一个测试来开始你的下一个周期，而是测试以涵盖由于重构而发生的任何变化。

这可能最好用一个真实的例子来解释。在 TDD 循环的绿色之后，我们有以下代码:

    public bool ShouldVerifyDomain
    {
        get
        {
            return this.Orders.SelectMany(x => x.Items).Any(x => x.Product.RequiresDomainVerification);
        }
    }

现在，我看着这个，然后想，嗯，那个 linq 语句可以更简洁一点，更容易阅读一点，不要太违反 Demeter，让我们重构它。所以我在 Order 上创建了以下内容:

 public bool HasItemsThatRequireDomainVerification
 {
     get
     {
          return this.Items.Any(x => x.Product.RequiresCascadeDomainVerification);
     }
 }

并将 ShouldVerifyDomain 修改为:

  public bool ShouldVerifyDomain
  {
      get
      {
           return this.Orders.Any(x => x.HasItemsThatRequireDomainVerification);
      }
  }

好的，看起来好多了，我对此感到满意。让我们继续我列表中的下一个测试......但是......等等，我们现在正在通过另一个对象上的属性测试属性 HasItemsThatRequireDomainVerification......这是一个真正的单元测试或者我应该添加一个测试来直接测试 HasItemsThatRequireDomainVerification。

我的感受？我看不出它会增加多少值(value)。我认为这会增加套件的维护负担，需要时间并且在进行 future 更改时不会真正给我们更多的信心。

它能给我们带来什么？ Order 公共(public)接口(interface)的“文档”。

想法？

Answer 1

您的重构步骤是否添加或更改了功能？如果是这样，那么这是一个无效的重构步骤。您应该首先取消这些更改并为新功能添加测试。

但是，在您的示例中，我认为情况不一定如此。您所做的一切与提取方法非常相似。您将现有逻辑合并到另一个位置并从现有位置调用它。现有的测试仍然在测试这个。

重构后，如果您担心需要添加更多测试，那么首先应该查看的是测试覆盖率。如果您仍处于 100%(或与重构前一样接近 100%)，那么您可能仍然很好。另一方面，如果重构添加了测试未涵盖的代码路径，那么您有一些选择:

• 您的代码需要那些代码路径吗？如果是这样，则测试不充分。您应该取消重构，为新的代码路径添加失败的测试，然后添加新的代码路径。
• 如果您的代码不需要这些代码路径，那么它们为什么在那里？摆脱它们。

您所问的与以多种形式提出的有关测试覆盖率的古老问题非常相似:

• 我应该测试私有(private)成员吗？
• 我应该为每种方法编写单独的测试吗？
• 每个对象的每个成员都应该进行测试吗？

与所有事情一样，答案始终是“视情况而定”。所有代码都应该进行测试，但每一行代码都不需要自己的测试。例如，假设我有一个类的属性:

public class Customer
{
    public string Name { get; set; }
}

我是否需要编写一个实例化 Customer 的测试，向其写入一个 Name 值，然后断言它可以读回相同的值？显然不是。如果失败，则说明存在一些很深的错误。但是，这行代码应该被测试覆盖吗？绝对地。某处应该有一个使用 Customer 的 Name 的测试。如果没有，如果系统中没有测试使用此属性，则测试不完整或系统实际上不需要此属性，应将其删除。

换句话说，当您编写测试时，您并没有真正测试代码。您正在测试系统的功能。实现该功能的代码与测试分开并与之并行。两人不需要了解彼此的很多细节。如果某些东西的外部可见功能发生变化，则测试应该更改以匹配(并验证)它。如果外部可见的功能没有改变，那么测试也不应该改变。他们仍应验证相同的功能。