您何时在TDD中编写“真实”代码？

#1 楼

如果我有一个使用复杂方法的相当复杂的对象，并且我编写了
测试和最基本的条件以使其通过（在第一次失败后，
红色）。我什么时候回去写真实的代码？在重新测试之前我要写多少真实代码？我猜想最后一个是
更直观。这都是真实的代码。您要做的是返回并添加另一个测试，该测试迫使您更改代码以通过新测试。

在重新测试之前要编写多少代码？没有。您编写零代码而没有失败的测试，该测试迫使您编写更多的代码。

注意图案吗？

让我们通过另一个简单的示例，希望对您有所帮助。

 Assert.Equal("1", FizzBuzz(1));
 

简单易学。

 public String FizzBuzz(int n) {
    return 1.ToString();
}
 

不是真正的代码，对吧？让我们添加一个强制更改的测试。

 Assert.Equal("2", FizzBuzz(2));
 

我们可以做一些愚蠢的事情，例如if n == 1，但我们会跳到理智的状态解。

 public String FizzBuzz(int n) {
    return n.ToString();
}
 

很酷。这将适用于所有非FizzBu​​zz编号。下一个将迫使生产代码更改的输入是什么？

 Assert.Equal("Fizz", FizzBuzz(3));

public String FizzBuzz(int n) {
    if (n == 3)
        return "Fizz";
    return n.ToString();
}
 

再说一次。编写尚未通过的测试。

 Assert.Equal("Fizz", FizzBuzz(6));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    return n.ToString();
}
 

我们现在已经覆盖了三个的所有倍数（不是倍数）五分之一，我们会记下来然后再回来）。

我们还没有为“嗡嗡声”编写测试，所以让我们来编写它。

 Assert.Equal("Buzz", FizzBuzz(5));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n == 5)
        return "Buzz"
    return n.ToString();
}
 

同样，我们知道还有另一种情况需要处理。

 Assert.Equal("Buzz", FizzBuzz(10));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n % 5 == 0)
        return "Buzz"
    return n.ToString();
}
 

现在我们可以处理5的所有倍数，而不是3的倍数。

到现在为止，我们一直忽略重构步骤，但是我发现有些重复。让我们现在清理一下。

 private bool isDivisibleBy(int divisor, int input) {
    return (input % divisor == 0);
}

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
}
 

很酷。现在，我们删除了重复项，并创建了一个命名良好的函数。我们可以编写的下一个将迫使我们更改代码的测试是什么？好吧，我们一直在避免数字被3和5整除的情况。让我们现在来编写它。

 Assert.Equal("FizzBuzz", FizzBuzz(15));

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n) && isDivisibleBy(5, n))
        return "FizzBuzz";
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
}
 

测试通过了，但是重复很多。我们有选项，但是我要多次应用“提取局部变量”，以便我们重构而不是重写。

 public String FizzBuzz(int n) {

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
}
 

我们已经介绍了所有合理的输入，但是不合理的输入呢？如果传递0或负数会怎样？编写那些测试用例。

 public String FizzBuzz(int n) {

    if (n < 1)
        throw new InvalidArgException("n must be >= 1);

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
}
 

这看起来像“真实代码”吗？更重要的是，在什么时候它不再是“虚幻的代码”，而是过渡到“真实的”？这是需要考虑的问题...

因此，我能够通过寻找我知道不会在每个步骤中通过的测试来简单地做到这一点，但是我已经做了很多练习。当我在工作时，事情从来都不是那么简单，而且我可能并不总是知道哪种测试将迫使变革。有时候我会写一个测试，惊讶地发现它已经通过了！我强烈建议您在开始之前养成创建“测试列表”的习惯。该测试列表应包含您可以想到的所有“有趣”输入。您可能不会全部使用它们，并且可能会随时添加案例，但是此列表可作为路线图。我的FizzBu​​zz测试列表如下所示。


负数
零
一个
两个
三个
四个
五个
六个（非平凡的3的倍数） ）
九（3平方）
十（5的非平凡倍数）
15（3和5的非凡倍数）
30（3和5的非平凡倍数）

#2 楼

“真实”代码是您编写以通过测试的代码。真。就这么简单。

当人们谈论编写最低限度的测试以使测试变为绿色时，这仅意味着您的实际代码应遵循YAGNI原则。

重构步骤只是在满足您的要求之后就清理您编写的内容。

，只要您编写的测试实际上包含您的产品要求，则这些测试通过那么代码就完成了。考虑一下，如果您的所有业务需求都具有测试并且所有这些测试都是绿色的，那么还有什么要写的呢？ （好吧，在现实生活中，我们往往没有完整的测试范围，但是理论是合理的。）

#3 楼

简短的答案是“真实代码”是使测试通过的代码。如果您可以通过真实代码以外的其他方式通过测试，请添加更多测试！

我同意很多有关TDD的教程都过于简单。那对他们不利。对于计算3 + 8的方法而言，过于简单的测试实际上别无选择，只能计算3 + 8并比较结果。这样就好像您将要遍历整个代码一样，并且测试是毫无意义的，容易出错。额外的工作。应用程序以及如何编写代码。如果您在提出明智，有用的测试方面遇到困难，则可能应该重新考虑一下您的设计。设计良好的系统易于测试-意味着明智的测试易于思考和实施。他们通过了，这是确保所有代码都有相应测试的准则。在编码时，我不会从容地遵循该规则。我经常在事实之后写测试。但是首先进行测试有助于保持诚实。有了一些经验，即使当您不首先编写测试时，也会开始注意到何时将自己编码到一个角落。

#4 楼

有时关于TDD的一些示例可能会误导您。
正如其他人之前指出的那样，您编写的用于使测试通过的代码是真实的代码。代码看起来像魔术一样-这是错误的。
您需要对要达到的目标有更好的了解，然后需要从最简单的案例和极端案例开始进行相应的测试。

例如，如果您需要编写词法分析器，则从空字符串开始，然后从一堆空白开始，然后是一个数字，然后是被空格包围的数字，然后是错误的数字，等等。这些小的转换将使您正确的算法，但是您不会从最简单的情况过渡到为完成实际代码而笨拙地选择的高度复杂的情况。

Bob Martin在这里完美地解释了它。

#5 楼

当您很累并且想回家时，重构部分会清理。

当您要添加功能时，重构部分就是您在下一次测试之前所做的更改。您可以重构代码以为新功能腾出空间。当您知道新功能将是什么时，就可以执行此操作。并非只是在想象中。

这就像在创建GreetImpl类（添加测试后）以添加将打印“ Hi Mom”的功能之前将GreetWorld重命名为GreetMom一样简单。

#6 楼

但是实际代码将出现在TDD阶段的重构阶段。
即

每次更改时都应运行测试。

TDD生命周期的座右铭是：红色绿色REFACTOR

RED：编写测试

GREEN：诚实尝试获得尽快通过测试的功能代码：重复的代码，名称晦涩难懂的变量顺序等。

REFACTOR：清理代码，正确命名变量。干燥代码。

#7 楼

什么时候在TDD中编写“真实”代码？


红色阶段是编写代码的地方。

在重构阶段，主要目标是删除代码。在红色阶段，您需要做任何事情，以使测试尽快通过，并且不惜一切代价。您完全无视关于良好编码实践或设计模式的任何经验。使测试变成绿色就很重要。

在重构阶段，您将清理刚刚产生的混乱。现在，您首先看看您所做的更改是否是“转换优先级”列表中最重要的更改，并且如果有任何代码重复，您可以通过应用设计模式将其删除。通过重命名标识符并将魔术数字和/或文字字符串提取为常量来提高可读性。



它不是红色分解，而是红色-绿色分解。 – Rob Kinyon


谢谢你指出这一点。您编写可执行规范的红色阶段...

#8 楼

您一直在编写真实代码。
您在编写代码的每一步都是为了满足您的代码满足将来对您代码的调用者（可能是您或不是您）的条件。
您认为您没有在编写有用的（真实的）代码，因为您可能会暂时重构它。分解-不更改其外部行为。

这意味着即使您正在更改代码，代码满足的条件也保持不变。以及为验证您的代码而实施的检查（测试）是否已存在，以验证您的修改是否有任何更改。因此，您一直编写的代码都以不同的方式存在于其中。
您可能会认为这不是真正的代码，另一个原因是您正在编写示例，其中最终程序可能已经由您预见了。 。这非常好，因为它表明您已经了解要编程的领域。他们不知道最终结果是什么，而TDD是一种逐步编写程序的技术，它记录了我们对该系统应该如何工作的知识，并验证了我们的代码是否可以那样工作。
当我阅读The关于TDD的书（*），对我而言，最重要的功能是：TODO列表。它向我表明，TDD还是一种技术，可以帮助开发人员一次专注于一件事情。因此，这也是对您的问题的答案，要写多少实际代码？我会说足够多的代码一次只关注一件事。
（*）肯特·贝克（Kent Beck）的“测试驱动开发：通过示例”

#9 楼

您不是在编写使测试失败的代码。

您在编写测试以定义成功的样子，而最初应该全部失败，因为您尚未编写将通过的代码。

编写最初失败的测试的整个目的是要做两件事：


覆盖所有情况-所有名义情况，所有边缘情况，等等
验证您的测试。如果只看到它们通过，您如何确定它们在发生故障时能够可靠地报告故障？知道编写的用于通过测试的代码是正确的，并且可以让您放心地重构，以便一旦出现问题，测试将立即通知您，因此您可以立即返回并对其进行修复。

以我自己的经验（C＃/。NET），纯测试优先是一个无法实现的理想，因为您无法编译对尚不存在的方法的调用。因此，“首先测试”实际上是首先对接口进行编码和存根实现，然后针对存根（最初会失败）编写测试，直到存根被正确充实。我从来没有写过“失败的代码”，只是从存根开始构建。

#10 楼

我认为您可能在单元测试和集成测试之间感到困惑。我相信可能还会有验收测试，但这取决于您的过程。

一旦测试了所有小的“单元”，然后就将它们组装或“集成”了。通常这是整个程序或库。

在我编写的代码中，集成测试使用各种测试程序来测试一个库，这些测试程序读取数据并将其馈送到该库，然后检查结果。然后我用线程来做。然后，我在中间使用线程和fork（）进行处理。然后运行它并在2秒后杀死-9，然后启动它并检查其恢复模式。我把它弄糊涂了。我以各种方式折磨它。

所有这些都还在测试中，但是结果没有漂亮的红色/绿色显示。它要么成功，要么我探究了几千行错误代码以找出原因。
这就是您测试“真实代码”的地方。这样，但是也许您不知道应该什么时候编写单元测试。当您的测试执行您指定的所有工作时，您就完成了单元测试的编写。有时，您可能会在所有错误处理和边缘情况中失去对这一点的了解，因此您可能希望创建一个很好的测试组，该测试组只需简单地通过规范即可。

评论

---

（它=所有格，它=“它是”或“它具有”。例如参见如何使用它和它。）

– Peter Mortensen
17年7月27日在16:08

---

#11 楼

在回答问题标题：“什么时候在TDD中编写“真实”代码？”时，答案是：“几乎不会”或“非常缓慢”。

学生，所以我会像建议学生一样回答。

您将学习很多编码“理论”和“技术”。它们非常适合在高价的学生课程上打发时间，但对您却几乎没有好处，因为您半个小时都无法读一本书。

编码员的工作仅仅是为了产生代码。代码效果很好。这就是为什么编码人员在头脑中，在纸上，在合适的应用程序等中计划代码的原因，并计划在编码之前通过逻辑和横向思考来预先解决可能的缺陷/漏洞。

但是您需要知道如何破坏您的应用程序才能设计出不错的代码。例如，如果您不了解Little Bobby Table（xkcd 327），那么在使用数据库之前您可能不会清理输入，因此您将无法围绕该概念保护数据。 br />
TDD只是一种工作流，旨在通过在编写应用程序之前创建可能出问题的测试来最大程度地减少代码中的错误，因为引入的代码越多，编码就会成倍增加，而您忘记的错误就越多你曾经想过。一旦您认为自己已经完成了应用程序，就可以运行测试并获得成功，希望测试中能够捕获bug。代码，编写另一个测试，以最少的代码获得通过，等等。相反，这是一种帮助您自信地进行编码的方法。不断重构代码以使其能够与测试一起使用的理想是白痴，但这在学生中是一个不错的概念，因为它使他们在添加新功能时仍感觉很好，并且仍在学习如何编写代码...

请不要落入这个陷阱，看看您的编码作用是什么-编码器的工作仅仅是产生代码。效果很好的代码。现在，请记住，您将是一名专业的编码员，这将使您全天候工作，并且您的客户端将不在乎您是否编写了100,000个断言（即0）。他们只希望代码有效。真的很好，