在“Programming Ruby 1.9 / 2.0”一书中，作者给出了一个网球记分员课程的例子，该课程将通过在实际代码之前编写一些RSpec测试来开发。
作者介绍了4项测试：
it "should start with a score of 0-0"
it "should be 15-0 if the server wins a point"
it "should be 0-15 if the receiver wins a point"
it "should be 15-15 after they both win a point"
然后作者建议读者应该继续写下这样的测试来完成课程：
it "should be 40-0 after the server wins three points"
it "should be W-L after the server wins four points"
it "should be L-W after the receiver wins four points"
it "should be Deuce after each wins three points"
it "should be A-server after each wins three points and the server gets one more"
（实际的TennisScorer Class为每位玩家添加分数，并以“15-15”的格式返回。
作者是否认为代码在30-15,15-30,0-30,30-0等分数下可以100％工作，只要测试成功为15-0,0-15 ，15-15？换句话说，没有必要明确地测试每个可能的分数？ 作者建议40-0测试，这是有道理的，因为40打破0-15-30大会（得分* 15），40-0测试足以表明40-30,15-40等将起作用还有吗？
另外，也许我对此过于复杂，但是在我的测试中有一个“随机游戏”，我在其中添加10万次随机分数并动态比较结果会不会更有意义？ （但我猜我的测试可能很容易包含一些错误..？）。 我想如果我要为乘法方法编写测试（例如，我会检查1 * 2 = 2并假设一切正常吗？），这将是要走的路。）
答案 0 :(得分：0)
使用tdd的要点是让您的规格和代码以较小的增量随时间增长。所以你应该从一些简单的事情开始，如上所述。但是，随着规范套件的增长以及代码的增长，您将感觉需要重构代码和规范。这很自然，应该是这样。我希望你的一个它的中的代码是对一个泛型方法的一行调用，该方法将输入传递给被测方法和预期结果。至少那是我经常来的地方。
根据上面的规范，您指出的代码可能不适用于30-15等。这取决于实现的结果。在这里添加更多规范并重用下面的测试代码是有意义的。
我建议不要在大多数情况下使用随机规格，因为你无法保证结果。如果代码本身具有随机行为，那么它可能有意义。我会尝试将随机性隔离到一个地方，以便其他地方可以确定性地进行测试。