在 TDD 重构之后编写更多单元测试答案

【问题标题】：Writing more unit tests after TDD refactor在 TDD 重构之后编写更多单元测试
【发布时间】：2013-07-16 14:26:59
【问题描述】：

这是我们反复讨论过的问题，人们对此的看法似乎大相径庭。

基本问题是，在进行 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。

我的感觉如何？我认为它不会增加太多价值。我认为这会增加套件的维护负担，需要时间，并且在进行未来更改时不会真正给我们更多信心。

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

想法？

【问题讨论】：

标签： c# unit-testing tdd

【解决方案1】：

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

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

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

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

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

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

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

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

我是否需要编写一个实例化Customer 的测试，向其写入Name 值，然后断言它可以读回相同的值？显然不是。如果失败了，那么严重出了点问题。然而，这行代码应该被测试覆盖吗？绝对地。在某个地方应该有一个使用Customer 的Name 的测试。如果没有，如果系统中没有测试使用此属性，则要么测试不完整，要么系统实际上不需要此属性，应将其删除。

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

【讨论】：

【解决方案2】：

当你在做 TDD 的时候，你的测试应该是功能级别的“功能测试”，所以只要功能没有改变，你就不应该改变你的测试。

只要功能的输入和输出相同，更改实现或重构在 TDD 中被视为细节。

TDD 不应导致您获得 100% 的覆盖率。

另一方面，如果您将单元测试用作代码解释或希望获得 100% 的覆盖率（我们在这里说的是单元测试，因为它们应该只针对一段代码），那么这些单元测试应该改变每次都调整实现以涵盖所有情况，但这不是 TDD 的目标。

【讨论】：

【解决方案3】：

你没有改变行为，只有语法。代码仍然以相同的方式工作，只是编写方式不同。我认为只要它仍然以相同的方式工作，您的单元测试就仍然可靠。

我认为，如果重构要求我们开始测试我们重构的新代码，我们最终会陷入困境。什么时候结束？

【讨论】：