用于测试多个数据点的 rspec 设计模式

Question

我经常发现，在为某个方法编写测试时，我想向该方法抛出一堆不同的输入，然后简单地检查输出是否是我所期望的。

作为一个简单的例子，假设我正在测试 my_square_function ，它对数字进行平方并智能地处理 nil。

下面的代码似乎可以完成这项工作，但我想知道是否有我应该使用的最佳实践（例如使用subject，context）：

describe "my_square_function" do
  @tests = [{:input => 1, :result => 1},
            {:input => -1, :result => 1},
            {:input => 2, :result => 4},
            {:input => nil, :result => nil}]
  @tests.each do |test|
    it "squares #{test[:input].inspect} and gets #{test[:result].inspect}" do
      my_square_function(test[:input]).should == test[:result]
    end
  end
end

建议？

谢谢！

（相关：rspec 重构？）

Answer 1

我将以所示的更简单的方式将输入和预期结果关联到哈希中，并迭代哈希：

describe "my_square_function" do
  @tests = {1  => 1,
            -1  => 1,
            2  => 4,
            nil => nil}

  @tests.each do |input, expected|
    it "squares #{input} and gets #{expected}" do
      my_square_function(input).should == expected
    end
  end
end

Answer 2

很抱歉回答这么长，但我想如果我经历了这一切，我的思维过程会更加连贯。

由于这个问题被标记为 TDD，所以我假设您正在编写 TDD 风格的方法。如果是这种情况，您可能需要从以下开始：

 describe "my_square_function" do
   it "Squares a positive number" do
     my_square_function(1).should == 1
   end
 end

测试失败，您可以按如下方式实现 my_square_function ：

 def my_square_function(number)
   1
 end

现在测试已经通过，您想要重构重复项。在这种情况下，重复是在代码和测试之间，即文字 1。由于参数携带测试的值，因此我们可以通过使用参数来删除重复。

 def my_square_function(number)
   number
 end

现在重复已被删除并且测试仍然通过，我们可以进入下一个测试：

 describe "my_square_function" do
   it "Squares a positive number" do
     my_square_function(1).should == 1
   end

   it "Squares a negative number" do
     my_square_function(-1).should == 1
   end
 end

运行测试，您再次遇到失败的测试，因此我们使其通过：

 def my_square_function(number)
   number.abs   # of course I probably wouldn't really do this but
                # hey, it's an example. :-)
 end

现在该测试通过了，是时候继续进行另一个测试了测试：

 describe "my_square_function" do
   it "Squares a positive number" do
     my_square_function(1).should == 1
   end

   it "Squares a negative number" do
     my_square_function(-1).should == 1
   end

   it "Squares other positive numbers" do
     my_square_function(2).should == 4
   end
 end

此时，您的最新测试将不再通过，因此现在要使其通过：

 def my_square_function(number)
   number.abs * number
 end

哎呀。这不太有效，它导致我们的负数测试失败。幸运的是，失败让我们回到了失败的确切测试，我们知道它由于“阴性”测试而失败。回到代码：

 def my_square_function(number)
   number.abs * number.abs
 end

那更好了，我们所有的测试现在都通过了。是时候再次重构了。在这里，我们在对 abs 的调用中看到了一些其他不必要的代码。我们可以摆脱它们：

 def my_square_function(number)
   number * number
 end

测试仍然通过，并且我们看到这个令人讨厌的论点有更多的重复。让我们看看是否可以摆脱它：

 def my_square_function(number)
   number ** 2
 end

测试通过，我们不再有重复的情况。现在我们有了一个干净的实现，接下来让我们处理 nil 情况：

 describe "my_square_function" do
   it "Squares a positive number" do
     my_square_function(1).should == 1
   end

   it "Squares a negative number" do
     my_square_function(-1).should == 1
   end

   it "Squares other positive numbers" do
     my_square_function(2).should == 4
   end

   it "Doesn't try to process 'nil' arguments" do
     my_square_function(nil).should == nil
   end
 end

好的，我们再次失败，我们可以继续实现 nil 检查：

 def my_square_function(number)
   number ** 2 unless number == nil
 end

这测试通过并且非常干净，所以我们将保持原样。现在我们回到规范，看看我们有什么，并验证我们喜欢我们所看到的：

 describe "my_square_function" do
   it "Squares a positive number" do
     my_square_function(1).should == 1
   end

   it "Squares a negative number" do
     my_square_function(-1).should == 1
   end

   it "Squares other positive numbers" do
     my_square_function(2).should == 4
   end

   it "Doesn't try to process 'nil' arguments" do
     my_square_function(nil).should == nil
   end
 end

我的第一个倾向是，我们真正描述的是“平方”数字的行为，而不是函数本身，所以我们将改变这一点：

 describe "How to square a number" do
   it "Squares a positive number" do
     my_square_function(1).should == 1
   end

   it "Squares a negative number" do
     my_square_function(-1).should == 1
   end

   it "Squares other positive numbers" do
     my_square_function(2).should == 4
   end

   it "Doesn't try to process 'nil' arguments" do
     my_square_function(nil).should == nil
   end
 end

现在，这三个示例名称在放入该上下文时有点模糊。我将从第一个示例开始，平方 1 似乎有点俗气。这是我为了减少代码中示例数量而要做的选择。我真的希望这些例子在某种程度上是有趣的，否则我不会测试它们。 1 和 2 的平方之间的差异并不有趣，因此我将删除第一个示例。一开始有用，但现在没用了。这给我们留下了：

 describe "How to square a number" do
   it "Squares a negative number" do
     my_square_function(-1).should == 1
   end

   it "Squares other positive numbers" do
     my_square_function(2).should == 4
   end

   it "Doesn't try to process 'nil' arguments" do
     my_square_function(nil).should == nil
   end
 end

我接下来要看的是反例，因为它与描述块中的上下文相关。我将为它和其余示例提供新的描述：

 describe "How to square a number" do
   it "Squaring a number is simply the number multiplied by itself" do
     my_square_function(2).should == 4
   end

   it "The square of a negative number is positive" do
     my_square_function(-1).should == 1
   end

   it "It is not possible to square a 'nil' value" do
     my_square_function(nil).should == nil
   end
 end

现在我们已将测试用例的数量限制为最有趣的测试用例，因此我们实际上没有太多需要处理的情况。正如我们在上面看到的，很高兴准确地知道失败发生在哪一行，以防这是我们预计不会失败的另一个测试用例。通过构建要运行的场景列表，我们失去了该功能，从而使调试故障变得更加困难。现在，我们可以用另一个解决方案中提到的动态生成的 it 块替换示例，但是我们开始失去我们试图描述的行为。

因此，总而言之，通过将您的测试场景限制为仅描述系统有趣特征的场景，您对太多场景的需求将会减少。在具有如此多场景的更复杂的系统上，可能会突出显示对象模型可能需要重新审视。

希望有帮助！

布兰登