当修复涉及更改测试签名下的方法时,如何使用TDD?

您陷入了TDD中最危险的陷阱:您认为TDD是关于测试的,但事实并非如此。然而,很容易落入这个陷阱,因为TDD中的所有术语都与测试有关。这就是BDD被发明的原因:它本质上是TDD,但没有令人困惑的术语。

在TDD中,测试不是真正的测试,而是示例。断言并不是真正的断言,而是期望。你不是在对付单位,而是在对付行为。BDD就是这么称呼他们的。(注意:BDD自发明以来一直在发展,现在它包含了不属于TDD的内容,但最初的意图只是“许多人做TDD是错误的,所以使用不同的词来帮助他们做正确的事情”。)

唯一正确的选择 ! 永远记住这一点!

当您发现单元的预期行为发生变化时,轰炸您的测试绝对没有错。

//Up front
[Test]
public void should_remove_correct_token_from_string()
{
  var text = "do.it.correctly..";
  var expected = "doitcorrectly";
  Assert.AreEqual(StaticClass.RemoveTokenFromString(text, "."), expected);
}

//After finding that it doesn't do the right thing
//Delete the old test and *design* a new function that
//Does what you want through a new test
//Remember TDD is about design, not testing!
[Test]
public void should_remove_correct_token_from_string()
{
  var text = "do.it.correctly..";
  var expected = "doitcorrectly";
  Assert.AreEqual(
      StaticClass.RemoveTokenFromString(
          text,
          ".",
          System.Text.Encoding.UTF8), expected);
}

//This will force you to add a new parameter to your function
//Obviously now, there are edge cases to deal with your new parameter etc.
//So more test are required to further design your new function

保持简单。

红色、绿色、重构

重构 打电话 Add Parameter

如果您的语言支持 method overloading

然后,当问题解决后,您可以逐个修改所有测试以调用新方法。最后,您可以删除旧方法。

这是一个有点广泛的过程,但我认为 遵循红-绿重构的TDD方法。

我要说的是,不要为“正确的”/“正确的”方式而烦恼。。。任何能帮助您更快地接近解决方案的方法。

如果您发现需要引入一个额外的参数,

• 更新测试用例中的调用
• 将新参数添加到实际方法中
• 继续把它变成绿色。

只有在添加一个新参数会导致无数编译错误的情况下,我才建议-分步执行。。。在发现确实不需要第三个参数或需要第四个参数之前,您不想更新整个源代码库。。浪费时间。因此,在更新所有引用之前,获取新版本的方法“working”。(正如菲利普在这里所说)

• 使用添加的参数写入新重载
• 使用新参数的一些默认值使旧重载继电器或委托给新重载
• 如果不再需要旧的重载,请删除它并修复由此产生的编译错误。

如果一个方法没有正确地完成任务,那么需要对其进行修复,如果修复需要更改签名,那么请注意其中的错误。根据TDD,您首先编写测试用例,它肯定会失败,然后编写方法以满足测试。按照这种方法,如果测试中的方法调用需要一个参数才能运行,那么您需要这样做。