testing - 一般应该如何使用 JUnit / 测试用例？

Question

我在一个一年前的 java/J2EE 项目上已经两个月了，每次现有的 JUnit 测试因为我而失败，那是因为 JUnit 测试已经过时或错误......所以我想知道“那些有什么用测试他们失败的唯一一次是因为方法的名称已更改，还是因为他们做错了“......

那么......我们应该在多大程度上实现测试用例，对于什么样的方法？在项目的哪个时刻，为什么？总结一下：关于测试用例有什么好的做法可以告诉我吗？

谢谢！

Answer 1

你问了十个问题，可以填满一本大书。
我试着回答一些：
什么
单元测试主要是针对模块测试，虽然也可以用于集成测试，但是集成范围是次要的。
单元测试的
发明者在引入“测试优先”（提前写好测试用例）这个词的时候，因为他认识的软件开发者大多是懒惰和不守纪律的。如果他建议稍后进行测试，那么许多测试将永远不会编写。
我的方法是，在完成 30% 后进行测试，否则你没有可用的结构进行测试。我称之为“早期测试方法”
，对
Junit 测试有用，但对用户界面测试不太有用，它不容易工作。
对于具有高度集成特性的模块，单元测试有点难以编写，（中央管理方法）
其余的它们非常有用。尤其是它们对于算法数学公式和各种计算都是必须的。

主要优点之一是通过编写单元测试，您可以避免在实际代码中进行耗时的调试。你失去编写单元测试的时间，你通过避免调试获得了时间。

高达 80% 的源代码语句的单元测试覆盖率，单元测试不会产生额外的项目成本。

我的经验表明，即使是 getter 和 setter 也应该进行单元测试，因为这可以在每节课 2 分钟内完成（在 testGetterSetter() 上使用 uisng）。去年，他在 setter 和 getter 中有两个严重的错误。

如果他们唯一失败是因为方法的名称已更改

如果你使用eclipse refactor->rename，那么Unit case会被包含在refactoring中，只要它们在同一个项目中，这是值得推荐的。
当然，源代码中的更改会导致需要将单元案例、src 和单元测试组合在一起形成一个单元。

最后，单元测试的主要优点之一是，当您创建包含一些更改的新版本时，您仍然知道所有单元测试都在运行。当您从离开公司的同事那里继承工作时，这一点尤其重要。