tdd – 测试驱动开发初始实现

TDD的一个常见做法是你做出微小的步骤.但有一件事让我感到烦恼的是我见过的一些人,他们只是硬编码值/选项,然后重构以使其正常工作.例如…

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

然后你尽可能让它通过:

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

它确实如此!

为什么人们会这样做?它是否确保他们实际上在正确的类或其他东西中实现该方法?因为它似乎是一种可靠的方式来引入错误并在忘记某些事情时给予虚假信心.这是一个好习惯吗?

解决方法

这种做法被称为“伪造它,直到你成功.”换句话说,将虚假实现放入其中,直到变得更简单地放入实际实现中.你问为什么我们这样做.

我这样做有很多原因.一个是确保我的测试正在运行.可能配置错误,以便当我点击我的魔术“运行测试”键时,我实际上没有运行测试,我认为我正在运行.如果我按下按钮并且它是红色的,那么放入假的实现并且它是绿色的,我知道我正在运行我的测试.

这种做法的另一个原因是保持快速的红/绿/重构节奏.这就是驱动TDD的心跳,重要的是它具有快速循环.重要的是让你感受到进步,这一点很重要,因此你知道你在哪里.有些问题(显然不是这个问题)无法通过快速心跳来解决,但我们必须在心跳中继续前进.伪造它直到你使它成为确保及时进展的一种方式.另见flow.

相关文章

迭代器模式(Iterator)迭代器模式(Iterator)[Cursor]意图...
高性能IO模型浅析服务器端编程经常需要构造高性能的IO模型,...
策略模式(Strategy)策略模式(Strategy)[Policy]意图:定...
访问者模式(Visitor)访问者模式(Visitor)意图:表示一个...
命令模式(Command)命令模式(Command)[Action/Transactio...
生成器模式(Builder)生成器模式(Builder)意图:将一个对...