JUnit 测试的建议
所有，
在为方法A（有很多内部条件）编写测试方法时，我应该每次都专注于测试单个条件吗？我发现很难为方法 A 构造一个覆盖方法 A 中所有代码路径的测试方法。
任何人都可以建议我如何编写测试方法吗？
All,
While writing a test method for method A (which has many internal conditions), should I focus on testing a single condition each time? I am finding it difficult to structure a test method for method A that would cover all the code path in method A.
Can anyone please suggest me how to go about writing a test method.?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您应该为每个执行路径编写一个测试。例如，如果有，
则应该测试 cond1 和 cond2。如果有意义的话，单独的测试方法是很好的并且值得鼓励。拥有
和
以及您需要的任何其他东西就可以了。
另外，当您说您的方法有“许多内部条件”时，也许您想重构代码，以便其中一些条件在其他更小的方法中处理，这些方法更容易测试。
you should write a test for every execution path. For example, if you have
you should test for cond1 and cond2. Separate test methods are fine and encouraged, if it makes sense. Its ok to have
and
and whatever else you need.
Also, when you say your method has 'many internal conditions', maybe you want to refactor your code so some of those conditions are handled in other, smaller methods, that are easier to test.
我的偏好是每个 JUnit 测试方法都有一个故障点。这意味着我正在测试的每个目标类方法将有许多 JUnit 测试方法。
在你的例子中，我可能有 testA1()、testA2()、testA3() 都测试相同的方法 (A)。其中每一个都会测试方法 A 的不同成功或失败条件。
如果有 8 个路径通过方法 A，那么您至少需要 8 个测试方法来调用它，也许还需要一些测试方法用于错误处理条件。
My preference is to have one failure point per JUnit test method. This means that I will have many JUnit test methods per target class method that I'm testing.
In your example, I may have testA1(), testA2(), testA3() all testing the same method (A). Each of these would test a different success or failure condition of method A.
If there are 8 paths through method A, then you need at least 8 test methods calling it and maybe some for error handling conditions.
首先，如果您的方法有多个职责，您应该考虑将其分解为多个方法。其次，我建议您为每种方法编写多个测试。每个测试都应该涵盖被测方法的特定路径。每个测试还应该（当然）根据您的测试数据给出预期结果。
First of all, you should consider breaking your method into several methods if it has more than one responsibility. Secondly, I would advice you to write multiple tests for each method. Each test should cover a specific path through the method under testing. Each test should also (of course) give the expected outcome depending on your test data.
测试应该比被测试的东西更简单，最好是简单得多。否则错误更有可能出现在你的测试中。因此，拥有许多小的简单测试方法来执行方法的一小部分比使用一个大而笨重的测试方法要好得多。 （您可以使用 Cobertura 等代码覆盖工具来验证您是否覆盖了方法中的所有路径。）
Tests should be simpler, preferably much simpler, than the thing tested. Otherwise the error is more likely to be in your test. So it's much better to have a lot of small simple test methods that execute small parts of your method than one big clunky one. (You can use a code coverage tool like Cobertura to verify that you're covering all paths in your method.)
不需要对每种方法进行一次测试。保持单元测试细粒度、描述性且易于理解。如果这意味着多个相似的测试都调用相同的目标方法，那么就这样做。
就此而言，尽量避免为每种方法系统地编写单元测试的习惯。单元测试应该经过深思熟虑，而不是习惯性的。它们应该描述类的行为，而不是单个方法的行为。
Do not feel the need to have one-test-per-method. Keep your unit tests fine-grained, descriptive, and easy to understand. If that means multiple, similar tests all calling the same target method, then do it.
For that matter, try and avoid the habit of systematically writing a unit test for each method. Unit testing should be well thought-out, not habitual. They should describe the behaviour of classes, rather than of individual methods.