编写最少的代码以通过单元测试-不作弊！

在进行TDD并编写单元测试时，如何在编写要测试的“实现”代码的第一次迭代时抵制“作弊”的冲动？

例如：
让我们需要计算一个数字的阶乘。我从一个单元测试开始（使用MSTest），例如：

[TestClass]
public class CalculateFactorialTests
{
    [TestMethod]
    public void CalculateFactorial_5_input_returns_120()
    {
        // Arrange
        var myMath = new MyMath();
        // Act
        long output = myMath.CalculateFactorial(5);
        // Assert
        Assert.AreEqual(120, output);
    }
}

我运行此代码，但由于该CalculateFactorial方法甚至不存在而失败。因此，我现在编写代码的第一次迭代以实现被测方法，并编写通过测试所需的最少 代码。

问题是，我一直很想写以下内容：

public class MyMath
{
    public long CalculateFactorial(long input)
    {
        return 120;
    }
}

从技术上讲，这是正确的，因为它确实是“作弊”，因为它实际上甚至没有尝试执行计算阶乘的功能，尽管它确实是进行特定测试通过（变为绿色）所需的最少代码。当然，现在重构部分成为“编写正确的功能”的练习，而不是真正的实现重构。显然，添加具有不同参数的其他测试将失败并强制进行重构，但是您必须从该测试开始。

因此，我的问题是，如何在“编写最少的代码以通过测试”同时又保持其功能与您实际试图实现的精神之间取得平衡？

完全合法。红色，绿色，重构。

第一次测试通过。

使用新输入添加第二个测试。

现在，快速变为绿色，您可以添加if-else，它工作正常。它通过了，但是您还没有完成。

红色，绿色，重构的第三部分是最重要的。 重构以消除重复。您现在将在您的代码中有重复项。两个返回整数的语句。 删除重复项的唯一方法是正确编码该函数。

我并不是说第一次就写不正确。我只是说如果不是这样就不会作弊。

显然，需要了解最终目标以及实现满足该目标的算法。

TDD并不是设计的灵丹妙药。您仍然必须知道如何使用代码解决问题，并且仍然必须知道如何以高于几行代码的级别进行测试。

我喜欢TDD的想法，因为它鼓励良好的设计；它使您考虑如何编写代码以使其可测试，并且通常，哲学将推动代码朝着更好的总体设计方向发展。但是您仍然必须知道如何设计解决方案。

我不赞成简化派的TDD哲学，这些哲学认为您可以通过编写最少的代码以通过测试来扩展应用程序。如果不考虑体系结构，这将行不通，您的示例证明了这一点。

鲍勃·马丁叔叔说：

如果您没有进行测试驱动开发，则很难称自己为专业人员。吉姆·科普林为此打电话给我。他不喜欢我这么说。实际上，他现在的立场是“测试驱动开发”正在破坏体系结构，因为人们正在编写放弃其他任何想法的测试，并在疯狂的匆忙中将其体系结构拆散以使测试通过，而他有一个有趣的观点，这是一种滥用仪式并失去纪律背后意图的有趣方式。

如果您不考虑架构，如果您正在做的事情是忽略架构并将测试放在一起并通过测试，那么您正在破坏将使建筑物保持正常运转的事物，因为这是集中在系统的结构以及有助于系统维持其结构完整性的可靠设计决策。

您不能简单地将一大堆测试放在一起，让它们十年又十年地通过并假设您的系统能够生存。我们不想让自己陷入地狱。因此，优秀的测试驱动开发人员始终意识到制定架构决策，始终考虑全局。

一个很好的问题...我不得不同意除@Robert以外的几乎所有人。

写作

return 120;

使阶乘函数通过一个测试是浪费时间。这不是“作弊”，也不是按照字面上的“红绿重构”。这是错误的。

原因如下：

• 计算阶乘是功能，而不是“返回常数”。“ return 120” 不是计算值。

• “重构”的论点被误导了；如果你有两个测试案例为5和6，该代码仍然是错误的，因为你不是计算阶乘都：

  if (input == 5) { return 120; } //input=5 case
  else { return 720; }   //input=6 case
  

• 如果我们从字面上遵循'refactor'参数，那么当我们有5个测试用例时，我们将调用YAGNI并使用查找表实现该功能：

  if (factorialDictionary.Contains(input)) {
      return factorialDictionary[input]; 
  }
  throw new Exception("Input failure");
  

这些都不是实际计算什么，你是。那不是任务！

如果只编写了一个单元测试，则单行实现（return 120;）是合法的。编写一个计算值120的循环- 可能会作弊！

这样简单的初始测试是捕获边缘情况并防止一次性错误的好方法。实际上，这不是我要输入的五个输入值。

这里有用的经验法则是：零，一个，很多，很多。零和一是阶乘的重要边缘情况。它们可以采用单线实施。然后，“许多”测试用例（例如5！）将迫使您编写一个循环。“很多”（1000 !?）测试用例可能会迫使您实施替代算法来处理非常大的数字。

只要您只有一个测试，那么通过该测试所需的最少代码就是真正的return 120;，只要您没有其他测试，就可以轻松地保留它。

这使您可以推迟进一步的设计，直到您实际编写使用此方法的其他返回值的测试为止。

请记住，测试是您规范的可运行版本，并且如果该规范说明的仅是f（6）= 120，则该声明非常合适。

如果您能够以这种方式“作弊”，则表明您的单元测试存在缺陷。

与其测试单个值的阶乘方法，不如测试一个值的范围。数据驱动的测试可以为您提供帮助。

将单元测试视为需求的体现-它们必须共同定义所测试方法的行为。（这被称为行为驱动的开发 -它的未来;-)）

因此，问问自己-如果有人将实现更改为不正确的内容，您的测试是否仍会通过，或者他们会说“稍等片刻！”？

请记住，如果您唯一的测试是问题中的测试，那么从技术上讲，相应的实现是正确的。然后，该问题被视为定义不明确的要求。

只需编写更多测试。最终，写起来会更短

public long CalculateFactorial(long input)
{
    return input <= 1 ? 1 : CalculateFactorial(input-1)*input;
}

比

public long CalculateFactorial(long input)
{
    switch (input) {
       case 0: return 1;
       case 1: return 1;
       case 2: return 2;
       case 3: return 6;
       case 4: return 24;
       case 5: return 120;
    }
}

:-)

对于“ OK”的足够小的值，编写“作弊”测试是可以的。但是，只有在所有测试均通过且无法编写将失败的新测试时，召回单元测试才完成。如果您真的想拥有一个包含一堆if语句（甚至更好的是一个大的switch / case语句:-）的CalculateFactorial方法，则可以这样做，并且由于您要处理的是固定精度的数字，因此所需的代码实现此操作是有限的（尽管可能相当大且难看，并且可能受编译器或系统对过程代码最大大小的限制所限制）。此时，如果您真的坚持所有开发都必须由单元测试来驱动，您可以编写一个测试，该测试要求代码在比遵循if语句的所有分支可以完成的时间短的时间内计算结果。

基本上，TDD可以帮助您编写能够正确实现需求的代码，但不能强迫您编写良好的代码。随你（由你决定。

分享并享受。

我确实100％同意Robert Harveys的建议，这不仅仅意味着通过测试，还需要牢记总体目标。

作为您“只有经过验证才能与给定的一组输入配合使用”这一痛点的解决方案，我建议使用数据驱动测试，例如xunit理论。此概念的强大功能在于，它使您可以轻松地创建输入到输出的规范。

对于阶乘，测试将如下所示：

    [Theory]
    [InlineData(0, 1)]
    [InlineData( 1, 1 )]
    [InlineData( 2, 2 )]
    [InlineData( 3, 6 )]
    [InlineData( 4, 24 )]
    public void Test_Factorial(int input, int expected)
    {
        int result = Factorial( input );
        Assert.Equal( result, expected);
    }

您甚至可以实现测试数据提供（返回IEnumerable<Tuple<xxx>>）并编码数学不变量，例如反复除以n将得到n-1）。

我发现此tp是一种非常强大的测试方法。

如果您仍然能够作弊，那么测试还不够。写更多测试！对于您的示例，我将尝试添加输入为1，-1，-1000、0、10、200的测试。

但是，如果您确实要作弊，则可以编写无尽的if-then。在这种情况下，除了代码审查之外，没有任何帮助。您很快就会被接受测试（由其他人撰写！）

单元测试的问题有时是程序员将它们视为不必要的工作。看到它们的正确方法是作为使您的工作结果正确的工具。因此，如果创建了一个if-then，则您会不知不觉地知道还有其他情况需要考虑。这意味着您必须编写另一个测试。依此类推，以此类推，直到您意识到作弊不起作用，最好以正确的方式编写代码。如果您仍然觉得自己还没有完成，那就还没有完成。

我建议您选择的测试不是最佳测试。

我将从以下内容开始：

阶乘（1）作为第一个测试，

第二阶乘（0）

阶乘（-ve）作为第三

然后继续处理非平凡的案件

并以溢出情况结束。