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

Question

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

我是否创建了冗余测试,我应该对每个要实现的方法只进行1次测试？

Answer 1

这通常不是我们在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个案例 - 但也许我会意识到我做得比这更快一点.

一个更好的问题是:我需要另一个测试吗？

@Wumbo，谢谢你的提问。是的，我仍然这样做。问题是，开发人员（你或我）并不愚蠢。我们知道（a）什么时候通过测试的逻辑块非常复杂，（b）什么时候我们的测试数量开始变得可笑。通过一次只编写一个愚蠢的测试，我们在每次传递时只有一点额外的逻辑，但在每个（绿色）点，我们所有的测试都通过了，因此我们有机会重构为更合理的东西。如果我们从完整的抽象解决方案开始，我们可能没有足够的测试。 (2认同)