编写JUnit测试用例的最佳规则

Question

我们有一个测试覆盖率> 80％的项目，但是代码的质量仍然是一个问题。 某些更改将带来测试用例涵盖逻辑的新错误。 编写JUnit测试用例的最佳规则是什么？

Answer 1

• 首先提示：开发新代码时，请在单元测试中开始做
• 不要从边界情况开始，测试为空
• 进行稳定的测试，这些测试不会随源变更而轻易中断
• 对于具有业务数据，序列的业务情景，请创建帮助功能
• 捕获回归错误，代码使用方面的弱点是主要目标
• 新代码通常值得重新设计，当一些其他功能具体化时就需要重写。 单元测试不应该是一种负担，也应该完全重写

一些努力可以更好地进入经过测试的代码。 100％的覆盖率还意味着测试代码及其维护需要投入大量精力。

但是，如果对源进行单元测试很麻烦，请通过划分职责来重构原始代码。 通过使用继承来分隔不同方面，可能很难做到这一点。

也依赖findbugs / coverity，硒等。

Answer 2

您说“有些变更会带来测试用例所涉及的新错误，以涵盖逻辑”。 我的问题是引入了哪种错误？ 这些功能性错误是否表示缺少功能或功能无法按预期运行，即使同时存在代码和单元测试也是如此。 然后我会说您需要做一些需求映射。 Junit不仅有助于涵盖“书面代码”，而且您还应该查看需求/方案，并且每种方案至少应有一个单元测试。 每次功能更改时，请确保先更新/添加Junit（这样它将开始失败），然后再更新/添加/删除代码。 因此，失败的Junit现在开始通过。