将单元测试引入现有项目

Question

我正在开发一个现有的Java EE项目，该项目包含在Eclipse中开发的各种maven模块，捆绑在一起并使用Java 1.6部署在JBoss上。我有机会准备任何框架并记录如何将单元测试带入项目。

你能提供任何关于......的建议吗？

• JUnit是我期望开始的地方，这仍然是Java开发人员的事实选择吗？
• 任何值得设置为标准的模拟框架？ JMock的？
• 应该设置的任何规则 - 代码覆盖，或确保它的单位而不是集成测试。
• 为项目经理制作花哨看起来输出的任何工具都可以讨好？

还有别的吗？提前谢谢。

Answer 1

关于单元测试框架，主要有两个：jUnit和TestNG。两者都有其优点，两者都具有同等的性能。 jUnit的主要优点是（在我看来）它的默认incoproration一个Eclipse插件允许简单的测试调用。

关于模拟框架，我发现它们不是测试方法的必需部分。当然它们很有用，但它们解决了一个特定的目的：测试行为（与测试接口相反 - jUnit允许的。使用模拟框架，您可以测试特定类如何实现特定接口。需要吗？显然。你先需要吗？我不知道。

关于规则，我发现唯一有用的是简单（一如既往）：“总是测试代码至少破坏一次。”考虑一下你的bug追踪器。每次遇到错误时，都必须进行单元测试，确保没有回归。在我看来，这是获得高质量代码的更快捷方式。

关于花哨和高效的输出，我建议你足够安装一个连续的集成服务器（Hudson，显然）。每次提交代码时它都会运行所有测试套件，以确保没有副作用。它将生成显示测试运行次数的图表，依此类推。它还可以集成代码覆盖工具和图形。这个持续集成的服务器将真正成为你的测试伙伴。

Answer 2

这是一个复杂的问题，所以关于我们在$ work中的实践的一些注释：

• JUnit确实仍然是标准。大多数文档和文献都对待JUnit。
• Mockito似乎是Java模拟中的新星，尽管我们仍然使用JMock并认为它对我们的需求很好。
• 我们使用EclEmma Eclipse插件来检查我们的测试覆盖率，并且喜欢它。

Answer 3

如果您尚未这样做，请通过Working Effectively with Legacy Code阅读Michael Feathers。

Answer 4

  

为项目经理制作花哨看起来输出的任何工具都可以讨好？

小心点。用于显示单位测试计数，覆盖范围，代码质量指标，行数，登记计数等指标的精彩工具在某些项目经理手中可能是危险的 。项目经理（不了解软件开发的实际情况）可能会对指标着迷，并且没有意识到：

• 他们没有真实反映项目的健康状况和进展情况，

• 他们可以完全假设个别团队成员的表现。

你可以得到一个愚蠢的情况，即经理给开发人员提供他们应该（例如）尝试为代码实现最大单元测试覆盖率的消息，而这是根本不保证的。时间花在无意义的工作上，重要的工作没有完成，错过了最后期限。

  

应该设置的任何规则 - 代码覆盖，或确保它是单位而不是集成测试。

• 代码覆盖对于可能易碎/错误的部分代码更为重要。不要求任何基准覆盖水平。

• 单元测试与集成测试取决于您正在构建的系统的性质和复杂性。

• 在事实之后添加大量单元级测试可能是浪费时间。它应该只针对被识别为有问题/需要维护工作的类别。

• 在事实有用之后添加集成级别测试，特别是如果项目原始开发人员不再使用。一个体面的集成测试套件有助于增加您的信心，即某些更改不会破坏重要的系统功能。但这需要明智地做到。测试网站外观的第N级测试套件可能是维持......和阻碍进步的噩梦。

Answer 5

我一直在为C ++项目改进单元测试，但这并不令人愉快。

我做的第一件事就是确定大多数'行动'的发生地点。然后使用它开始将单元测试放在可以轻松测试的函数上。

然后，一旦你有了更容易的那些，你就可以开始考虑扩展覆盖范围的病毒 - 攻击具有较少依赖性的函数，在调试器中运行它们几次，看看传入了什么值，然后用这些函数编写单元测试值，以确保你不会破坏任何东西。

不要指望快速修复 - 需要3周（6小时，每周5天）才能获得20％的覆盖率，但代码在该代码中花费了80％的时间，所以我认为花了很多时间并且发现了很多错误。

Answer 6

关于测试覆盖率，我认为当您将单元测试引入现有项目时，现在开始设置覆盖率预期还为时过早。您应首先确保您实际上可以集成测试框架并从coverage工具获取报告。完成后，您可以开始监控覆盖率，然后可以考虑目标。