在TDD中,我应该为方法编写多少个测试?

时间:2011-05-02 23:30:32

标签: c++ unit-testing testing tdd

我想实现一个方法,它告诉我坐标(x和y)是否超出范围。我应该写多少次测试?对我而言似乎是5:

  1. 测试负x超限
  2. 测试正x超限
  3. 测试负y超过界限
  4. 测试正y超过界限
  5. 测试有界限
  6. 我是否创建了冗余测试,我应该对每个要实现的方法只进行1次测试?

5 个答案:

答案 0 :(得分:8)

这通常不是我们在TDD中考虑它的方式。它更多:“我接下来需要什么测试?”所以,通常,我会从(伪代码)

开始
given: bounds (5, 10, 15, 20)
assert: outOfBounds(0, 0)

并使用

进行传递
outOfBounds(x, y): return true

但我知道那还不是真的,所以我知道我需要另外一次测试。

assert: !outOfBounds(5, 10)

所以现在失败了。什么是最简单的可能工作?也许

outOfBounds(x, y): return x == 0

当然我知道我还在假装它,所以我需要另一个测试。这种情况一直持续下去,直到我不再伪造它。也许,在这种情况下,我会结束与你的“多少次测试”问题相同的5个案例 - 但也许我会意识到我做得比这早一点。

更好的问题是:我还需要其他测试吗?

答案 1 :(得分:4)

你需要编写足够的测试来掩盖你希望从你的方法中看到的行为 - 不多也不少。

事实上,如果你正在练习TDD(正如标题所示)那么你的方法的行为应该是你所编写的测试所驱使的,而不是相反 - 所以你已经找到了最佳数字对你所写的功能进行测试以使它们通过。 (虽然在驱逐出快乐路径功能之后想到边缘情况和失败案例是很常见的,我猜这是在这里发生了什么?)

对于这个特定的情况,你在这里描述的五个测试对我来说听起来非常明智。

答案 2 :(得分:1)

前雇主聘请Kent Beck为我们的团队举办为期两天的TDD研讨会。我问了一些非常类似的东西,比如“如果你有足够的测试你怎么知道?”他的回答是“你觉得你有足够的考试吗?”当然,他并没有问“你觉得你今天做得不够好吗?”或者“你愿意钓鱼,如果是的话,就停止写测试。”他的观点是,当你认为自己已经筋疲力尽时,你的单位可以被测试并显示正常工作(或失败),那么你就完成了。

当然,当你发现该单位的一个错误时,你会发现“也许我没有完成”。然后添加更多测试,然后修复您的错误。

答案 3 :(得分:0)

在我看来,我会回到经验法则来测试好数据,坏数据,没有数据。因此,对于具有一个输入和返回值的方法,我认为我至少需要三次测试。我想听听其他人对这种方法的看法。

答案 4 :(得分:-3)

我个人会说你需要一个测试用例。

在这种情况下,您应该检查所需的所有边界。

所以,1个测试'方法'检查5个边界。