0

在“Programming Ruby 1.9/2.0”一书中，作者给出了一个 Tennis Scorer 类的示例，该类将通过在实际代码之前编写一些 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 类为每个玩家添加分数，并以“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 等会起作用也？

另外，也许我过于复杂了，但是在我的测试中添加随机分数 100000 次并动态比较结果的“随机游戏”不是更有意义吗？（但我想我的测试可能很容易包含一些错误..？）。我认为如果我要为乘法方法编写一个测试，这将是一种方法（或者我会检查 1*2 = 2 并假设一切正常？）

4

1 回答 1

0

tdd 的重点是让您的规范和代码随着时间的推移以小增量增长。所以你应该从一些简单的事情开始，就像上面概述的那样。然而，随着您的规范套件和代码的增长，您将感到需要重构代码和规范。这是自然的，也应该如此。我希望您的其中一个代码中的代码是对通用方法的单行调用，该方法将输入输入到被测方法和预期结果。至少那是我经常去的地方。

正如您所指出的，使用上面的规范，代码可能不适用于 30-15 等。这取决于实现的结果。在这里添加更多规范并重用下面的测试代码是有意义的。

在大多数情况下，我建议不要使用随机规格，因为您无法保证结果。如果代码本身具有随机行为，那么它可能是有意义的。我会尝试将随机性隔离到一个地方，以便可以确定性地测试其余部分。

于 2013-10-04T11:20:41.333 回答