在 TDD 中，我应该为一个方法编写多少个测试？
我想实现一个方法来告诉我坐标（x 和 y）是否超出范围。我应该写多少个测试？对我来说，似乎是 5：
- 测试负 x 越界
- 测试正 x 越界
- 测试负 y 越界
- 测试正 y 越界
- 测试有界
我是否正在创建冗余测试，每个测试是否应该只有 1 个测试我想实现的方法？
I want implement a method which tells me if the coordinates (x and y) are out of bounds. How many tests should I write? To me it seems to be 5:
- Test for negative x over bound
- Test for positive x over bound
- Test for negative y over bound
- Test for positive y over bound
- Test for with bounds
Am I creating redundant tests and should I only have 1 test for each method I want to implement?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这通常不是我们在 TDD 中思考的方式。更多的是：“接下来我需要什么测试？”因此，通常，我会从（伪代码）开始
，并通过
但我知道这还不是真的，所以我知道我需要另一次测试。
所以现在失败了。最简单可行的方法是什么？也许
当然我知道我仍然在假装，所以我需要另一次测试。这种情况一直持续下去，直到我不再假装为止。也许，在这种情况下，我会得到与您在“有多少测试”问题中所做的相同的 5 个案例 - 但也许我会意识到我比这更早完成了。
更好的问题是：我需要另一次测试吗？
This isn't usually the way we think about it in TDD. It's more: "what test do I need next?" So, typically, I'd start with (pseudocode)
and make that pass with
But I know that's not real yet, so I know I need another test.
So now that fails. What's the simplest thing that could possibly work? Maybe
Of course I know I'm still faking it, so I need another test. This keeps going 'til I'm not faking it any more. Maybe, in this case, I'd wind up with the same 5 cases you do with your "how many tests" question - but maybe I'll realize I'm done a little sooner than that.
A better question is: Do I need another test?
您需要编写足够的测试来掩盖您期望从方法中看到的行为 - 不多也不少。
事实上，如果您正在练习 TDD（如标题所示），那么您的方法的行为应该由您编写的测试驱动，而不是相反 - 因此您已经找到了最佳测试数量您为使它们通过而编写的功能。 （虽然在排除快乐路径功能后通常会考虑边缘情况和失败情况，我猜这就是这里发生的情况？）
对于这个特定情况，您在这里描述的五个测试对我来说听起来完全合理。
You need to write sufficient tests to cover off the behaviour you expect to see from your method - no more, no less.
Indeed, if you're practising TDD (as the title suggests) then the behaviour of your method should have been driven out by the tests you wrote, rather than the other way around - so you will already have found the optimal number of tests for the functionality you've written to make them pass. (Though it's common to think of edge cases and failure cases after having driven out the happy-path functionality, which I guess is what's happened here?)
For this specific case, the five tests you've described here sound perfectly sensible to me.
一位前雇主聘请 Kent Beck 为我们团队举办为期两天的 TDD 研讨会。我问了他一些非常相似的问题，比如“你怎么知道你是否进行了足够的测试？”他的回答是“你觉得你的测试够多了吗？”当然，他并不是在问“你觉得今天的工作做够了吗？”或“你宁愿钓鱼吗？如果是，请停止编写测试。”他的观点是，当你认为你已经用尽了所有可以测试你的设备并显示其正常工作（或失败）的方法时，那么你就完成了。
当然，当您在该单元中发现错误时，您就会意识到“也许我还没有完成。”然后添加更多测试，然后修复错误。
A previous employer hired Kent Beck to do a two day seminar on TDD for our group. And I asked him something very similar, something like "How do you know if you have enough tests?" His answer was "Do you feel like you have enough tests?" Of course, he wasn't asking "Do you feel like you've done enough work for today?" or "Would you rather be fishing, and if so, stop writing tests." His point was, when you think you've exhausted all the ways your unit can be tested and shown to work (or fail) correctly, then you're done.
And of course, when you find a bug in that unit, then you realize "Maybe I wasn't done." Then you add more tests, and then fix your bug.
在我看来，我会回到用好数据、坏数据、无数据进行测试的经验法则。因此，对于具有一个输入和一个返回值的方法，我认为我至少需要三个测试。我想听听其他人对这种方法的看法。
In my opinion, I would revert back to the rule of thumb for testing with good data, bad data, no data. So for a method with one input and a return value, I would think I would need a minimum of three tests. I'd like to hear what others think of this approach.
我个人认为，您需要一个测试用例。
在这种情况下，您应该检查您需要的所有边界。
因此，1 测试检查 5 个边界的“方法”。
I would, personally, say that you need one test case.
Within that case you should check all the boundaries that you need to.
So, 1 test 'method' that checks the 5 boundaries.