我们的项目包含2600个类文件——我们应该在哪里以及如何开始编写JUnit测试?

在你改变某些东西之前,为你遇到的每一个bug编写一个单元测试。

换句话说,测试您当前正在处理的功能。否则,为所有类编写测试将花费大量的时间和精力。

开始为提交的每个bug编写测试(编写测试,观察失败,修复bug,再次测试)。也要先测试新特性(它们更可能有错误)。开始时速度会很慢,但是随着测试基础结构的增长,它会变得更容易。

如果使用Java 5或更高,则使用JUnit 4。

了解单元测试、集成测试和验收测试的区别。也可以看看模仿。

其他答案给出了有用的建议,但我错过了对基本原则的清晰表述:努力 最大限度地从你的努力中获益 . 在很大程度上,用单元测试覆盖一个大型的遗留代码库需要花费大量的时间和精力。你想从一开始就把你的努力的结果最大化。这不仅在早期提供了有价值的反馈,而且有助于说服/保持管理层和其他开发人员的支持,相信这项工作是值得的。

所以

• 从测试最广泛功能的最简单方法开始 ,通常是系统/集成测试,
• 确定关键的核心功能 把重点放在这个系统上,
• 识别变化最快/最不稳定的部分 把重点放在这些系统上。

不要先尝试单元测试。执行覆盖大量代码的系统测试(端到端测试)。为所有人编写单元测试 新的 代码。

这样就可以用系统回归测试稳定旧代码。随着越来越多的新代码进入没有单元测试的代码部分,代码开始逐渐消失。在没有系统测试的情况下为旧代码编写单元测试很可能会破坏代码,并且由于代码编写时没有考虑可测试性,因此需要做很多工作来证明其合理性。

你可以找到迈克尔·费瑟的书 Working Effectively with Legacy Code 有用的。

你现在已经相当笨拙了,但是写一些测试来支持你所拥有的最关键的代码。例如,如果您的代码允许基于用户权限的功能,那么这是一个很重要的测试。camelCase名称并将其写入日志文件的例程?没那么多。

“如果这个代码坏了,它能吸多少钱”是一个很好的试金石测试。

“我们的内部维护屏幕在IE6上看起来会很糟糕”是一个答案。 “我们会给每个客户发送10000000封电子邮件”是另一个答案。

你先考哪门课,呵呵。

你可能会发现这本书相关而有趣。作者解释了如何做你在这里所要求的。

http://my.safaribooksonline.com/0131177052

哦,还有一件事——没有足够的单元测试比没有好得多。如果你能做到的话,一次加几个。不要放弃。