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

Question

我想要实现一个方法，它告诉我坐标(x和y)是否超出了界限。我应该写多少个测试？对我来说似乎是5：

1. 检验负x超过束缚
2. 检验阳性x超过束缚
3. 检验负y超过束缚
4. 测试阳性y超过界限

<代码>H19测试范围<代码>H 210<代码>G 211

我是否创建了多余的测试，对于我想要实现的每个方法，我应该只有一个测试吗？

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个案例--但也许我会意识到，我会更快地完成任务。

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

Answer 2

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

实际上，如果您正在实践TDD (如标题所示)，那么您的方法的行为应该会被您编写的测试排除在外，而不是相反--所以您已经为您编写的通过测试的功能找到了最佳测试数量。(虽然在排除了愉快路径功能之后，人们通常会想到边缘案例和失败案例，但我猜这里发生了什么呢？)

对于这个具体的情况，您在这里描述的五个测试在我看来是非常明智的。

Answer 3

一位前雇主雇佣肯特·贝克为我们的团队举办为期两天的TDD研讨会。我问他一些类似的问题，比如“你怎么知道你是否有足够的测试？”他的回答是“你觉得你有足够的测试吗？”当然，他不是在问“你觉得今天的工作做得够多了吗？”或者“你宁愿钓鱼，如果是的话，停止写测试。”他的观点是，当你认为你已经用尽了所有的方法，你的单位可以测试和显示正确的工作(或失败)，那么你就完成了。

当然，当你在那个单元中发现一个窃听器时，你就会意识到“也许我还没完成。”然后添加更多的测试，然后修复您的bug。