如何保证junit测试的质量？
是否有经过验证的方法来验证 junit 测试或集成测试的质量？
您的业务分析师是否应该检查单元测试的准确性？或者还有其他方法吗？ 在传统的代码优先环境中，同行或领导会审查测试计划，但是自动化测试怎么样？
我查看了 这个 stackflow 线程，但无法提取任何有意义的内容。
想法？
Are there proven ways of verifying quality of junit tests or integration tests?
Should your business analyst review unit tests to cerfity? Or are there any other ways?
In the traditional code first environment a peer or lead would review the test plan but how about automated tests?
I looked at this stackflow thread but couldn't extract anything meaningful stuff.
Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
突变测试和代码覆盖率可以验证您的测试的质量。
因此，首先检查您的代码覆盖率是否足够高。经过突变测试验证后，您的测试结果良好。突变测试工具对生产代码进行微小更改并重新运行测试 - 修改后，良好的测试应该会失败。有关 Java 中的突变测试工具，请参阅 PIT 突变测试 和此博客文章：PIT 和 TestNG 突变测试简介
但这仍然是还不够，测试应该写得好并且可读。因此，您还需要代码审查以及测试的质量规则验证。我推荐一本关于编写良好测试的好书实用单元测试。第 10 章：可维护的测试是免费提供的。
Mutation testing and code coverage can verify the quality of your tests.
So first check than your code coverage is high enough. After this verify with mutation testing than your test are good. Mutation testing tool makes small change(s) in production code and reruns test - after a modification a good test should fail. For mutation testing tool in Java look at PIT Mutation Testing and this blog post: Introduction to mutation testing with PIT and TestNG
But this is still not enough, tests should be good written and readable. So you need code review also and quality rules verification for tests. I recommend nice book about writing good tests Practical Unit Testing. Chapter 10: Maintainable tests from this book is available for free.
这是一篇很好的链接文章：
http://www .ibm.com/developerworks/java/library/j-cq01316/index.html?ca=drs
并且：
良好的测试 ⇒ 高覆盖率
高覆盖率⇒/⇒ 良好的测试
覆盖率工具可用于确定项目的哪些区域需要更多关注，但这并不意味着具有良好覆盖率的区域不需要更多关注。
Here's a nice linked article:
http://www.ibm.com/developerworks/java/library/j-cq01316/index.html?ca=drs
And:
Good Tests ⇒ High Coverage
High Coverage ⇒/⇒ Good Tests
Coverage tools are useful to identify what areas of your project need more attention, but it doesn't mean that areas with good coverage shouldn't need more attention.
代码覆盖工具是一个好的开始，但是知道给定的行已执行并不意味着它已经过测试。没有断言或
expected=Exception.class的臭名昭著的测试用例就是一个例子。我可以想象这个级别上的几个标准：
一个人可能会尝试自动化第一个测试，其他测试或多或少是主观的。
至于进行测试审查的分析师 - 可能只有 Fitense 装置的可读性足以满足非开发人员的需求。
Code coverage tool is a good start, but knowing that a given line was executed does not mean it was tested. Infamous test cases without assertions or
expected=Exception.classare an example.I can imagine few criteria on this level:
One might try to automate the first one, others are more or less subjective.
As for analyst doing test review - probably only Fitensse fixtures are readable enough to satisfy non-developers.
代码审查是保证测试质量的最佳方式。我不会让业务分析师审查测试，因为一个简单的事实是他们可能没有接受过理解测试所需的培训。此外，单元测试并不都存在于分析师要求的功能级别。分析师可能会说“当用户单击保存时，配置文件就会被保存”，而您可能必须跨多个层编写 n 个测试才能获得该功能。
Code review is the best way to ensure test quality. I would not have business analysts review the tests, for the simple fact that they might not have the training necessary to understand the tests. Also, unit tests do not all live at the functional level, where analysts' requirements are. An analyst might say 'when the user clicks save, the profile is saved' whereas you might have to write n number of tests across multiple layers to get that functionality.
您可以考虑使用代码覆盖率工具来确保 100% 的代码行都经过测试。 Emma是一个很好的java工具（http://emma.sourceforge.net/）。
You might consider code coverage tools to ensure 100% of the code lines are being tested. Emma is a good tool for java (http://emma.sourceforge.net/).