处理过时测试的最佳实践

Question

在代码战争中，我正在经历一个非常基本的挑战。挑战是测试一个返回平方数组之和的方法。

到目前为止，我的测试是：

describe "square method" do   
  it "should return the square of a number" do

    Test.assert_equals(squareSum(4), [16])

  end

  it "should return the square of multiple numbers" do 

    Test.assert_equals(squareSum(4, 2, 3), [16, 4, 9])

  end
end

我的代码是：

def squareSum(*numbers)
  numbers.map { |num| num ** 2 }
end

现在，我需要修改它，这样它就可以加法了。在我看来，这肯定否定了之前的两次测试。就TDD最佳实践而言，我是否很可笑地测试了前两种场景，因为它们不是我想要得到的方法呢？我该如何继续我的下一个测试？

我是否应该：

• 删除前两个测试，因为一旦我更改方法，它们就会失败？
• 找到一种方法，使之前的两个测试都不会失败，即使我已经更改了它？

在处理这个问题时，我是否应该不担心前两次测试呢？我对这个问题的措辞有相当大的困难。基本上，我知道我想要的是：

describe "squareSum method" do 
  it "should return the sum of the squares of the numbers passed" do 

    Test.assert_equals(squareSum(1, 2, 2), 9)

  end
end

有代码才能让它正常工作。我只是想知道测试的最佳实践是什么--驱动这种特殊的问题，因为我想测试一下，在返回和之前，我可以返回多个数字的平方。我的“最后”代码将使初始测试过时。这是一个“我的工作应该有多少在最终的解决方案？”，挑剔和某种肛门保留的问题，我认为。但我很好奇。

Answer 1

既然测试是您打算编写的软件的规范，那么问题是为什么要为您不想要的东西编写规范(因为挑战的任务不是编写一个对其参数进行平方的函数)？

首先，您应该为“返回平方数组之和的方法”编写规范。这个测试开始是红色的。

然后，您可能会决定需要一个将其参数(或给定数组的元素)平方作为中间步骤的函数。为这个函数编写一个测试。通过实现这样一个函数，使其变得绿色。

最终将所有的东西放在一起，并使您的初始测试变成绿色(您的主函数可以使用助手函数并总结它的返回值)。

不，你可以重构。如果在重构期间，您决定不再需要助手函数:删除该函数并删除其测试。

另外，当您的规范发生变化时，您需要重写您的测试，编写新的测试，甚至删除其中的一些测试。

但一般规则是:测试始终是软件当前状态的规范。他们应该确切地指定您的软件的意图。没有更多，没有更少。