测试驱动开发初始实现

Question

TDD的一种常见做法是，您可以进行微小的步骤。但有一件事困扰着我，我见过一些人这样做，他们只是硬编码值/选项，然后稍后进行重构以使其正常工作。例如…

describe Calculator
  it should multiply
    assert Calculator.multiply(4, 2) == 8

然后你做最不可能的事情让它通过：

class Calculator
  def self.multiply(a, b)
    return 8

事实的确如此！

人们为什么要这样做？这是为了确保他们真正在正确的类中实现方法吗？因为如果你忘记了什么，这看起来就像是引入错误并给出错误信心的一种可靠的方式。这是一个很好的实践吗？

Answer 1

这种做法被称为“伪装，直到你实现它”。换句话说，把假的实现放进去，直到真正的实现变得更简单。你会问我们为什么要这样做。

我这样做有很多原因。一个简单的方法是确保我的测试正在运行。可能是配置错误，所以当我按下神奇的“运行测试”键时，我实际上并没有运行我认为我正在运行的测试。如果我按下按钮，它是红色的，然后放入假的实现，它是绿色的，我知道我真的在运行我的测试。

这种做法的另一个原因是保持快速的红色/绿色/重构节奏。这是驱动TDD的心跳，重要的是它有一个快速的周期。重要的是让你感觉到进步，重要的是你知道自己所处的位置。有些问题(显然不是这个)不能在一个快速的心跳中解决，但我们必须在心跳中解决它们。伪装直到你做到这一点是确保及时进步的一种方式。参见flow。

Answer 2

有一种学派认为，你不应该有任何不属于单元测试的源代码行，这对培训程序员使用TDD很有用。通过首先编写将测试传递到测试中的算法，您可以验证您的核心逻辑是否工作。然后，将其重构为您的生产代码可以使用的东西，并编写集成测试来定义交互，从而定义包含此逻辑的对象结构。

此外，严格遵守TDD会告诉您，不应该存在由单元测试中的断言验证的需求没有明确声明的逻辑代码。举个例子；此时，系统中对乘法的唯一测试是断言答案必须是8。因此，此时答案始终是8，因为需求告诉您没有什么不同。

这似乎非常严格，在像这样的简单情况下，这是荒谬的；要在一般情况下验证正确的功能，您将需要无限数量的单元测试，当您作为一个聪明的人“知道”乘法应该如何工作时，可以很容易地设置一个测试，生成并测试一个乘法表，达到一定的限制，这将使您确信它将在所有必要的情况下工作。然而，在涉及更多算法的更复杂的场景中，这成为对YAGNI好处的有用研究。如果需求声明您需要能够将记录A保存到数据库，而忽略了保存记录B的能力，那么您必须得出结论：“您将不需要”保存记录B的能力，直到有需求表明这一点。如果您在知道需要之前实现了保存记录B的能力，那么如果事实证明您从来不需要这样做，那么您就浪费了时间和精力将其构建到系统中；您的代码没有任何业务目的，无论如何，它仍然会“破坏”您的系统，因此需要维护。

即使在较简单的情况下，如果您的代码超出了您“知道”的太轻或太具体的要求，那么您最终可能会编写比您需要的更多的代码。假设您正在实现某种类型的字符串代码解析器。需求声明字符串code "AA“= 1，"AB”= 2，这就是需求的极限。但是，您知道此系统中的完整代码库包括20个其他代码库，因此您需要包含解析完整代码库的逻辑和测试。你回到客户那里，等待你支付时间和材料，客户说“我们没有要求这样做；我们只使用了我们在测试中指定的两个代码，所以我们不会为额外的工作付钱给你”。他们是完全正确的；从技术上讲，您试图通过向他们不要求和不需要的代码收费来欺骗他们。