将单元测试引入现有项目答案

【问题标题】：Bringing unit testing to an existing project将单元测试引入现有项目
【发布时间】：2010-07-22 08:45:05
【问题描述】：

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

您能提供任何关于...的建议

还有什么？提前致谢。

【问题讨论】：

EasyMock 是最著名的模拟框架（看看谷歌搜索：P）。这个名字不像jMock那么酷，但它更好。但是，Mockito 允许您跳过创建模拟的一步（设置后不需要重播（模拟））。

【解决方案1】：

关于单元测试框架，主要有两个：jUnit和TestNG。两者都有各自的优势，并且都具有同等的性能。 jUnit 的主要优点是（在我看来）它默认包含一个 Eclipse 插件，允许轻松调用测试。

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

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

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

【讨论】：

这并不是模拟框架的真正目的。真正的目的是能够测试使用 InterfaceB 的 ClassA，并模拟 B 以测试 A 在 B 执行此操作时的行为 - 将 A 的测试与 B 的任何实现完全隔离（否则您将同时在同一时间，然后它就不是 unit 测试）。

【解决方案2】：

这是一个复杂的问题，所以只是关于我们在 $work 的实践的几点说明：

【讨论】：

【解决方案3】：

有什么工具可以生成精美的输出供项目经理讨好？

小心。用于显示单元测试计数、覆盖率、代码质量指标、行数、签入计数等指标的精美工具在某些项目经理的手中可能很危险。项目经理（不了解软件开发的实际情况）可能会沉迷于指标，却没有意识到：

您可能会遇到一些愚蠢的情况，即经理向开发人员发出信息，即他们应该（例如）尝试在根本没有保证的情况下为代码实现最大的单元测试覆盖率。时间花在无意义的工作上，重要的工作没有完成，错过了最后期限。

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

代码覆盖率对于可能脆弱/有缺陷的部分代码更为重要。不要强制要求任何基准覆盖率。
单元测试与集成测试取决于您正在构建的系统的性质和复杂性。
事后添加大量单元级测试可能是浪费时间。仅应针对被确定为有问题/需要维护工作的类进行。
事后添加集成级别测试很有用，尤其是在项目的原始开发人员不再存在的情况下。一个体面的集成测试套件有助于增强您对某些更改不会破坏重要系统功能的信心。但这需要明智地进行。测试网站外观和感觉的第 N 级的测试套件可能是维护的噩梦......并阻碍进步。

【讨论】：

【解决方案4】：

【讨论】：

【解决方案5】：

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

我做的第一件事是确定大部分“动作”发生的位置。然后使用它开始对可以轻松测试的功能进行单元测试。

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

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

【讨论】：

【解决方案6】：

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

【讨论】：