我正在开发一个现有的 Java EE 项目，其中包含在 Eclipse 中开发的各种 Maven 模块，捆绑在一起并使用 Java 1.6 部署在 JBoss 上。我有机会准备任何框架并记录如何将单元测试引入项目。
你能提供任何关于...的建议吗？
还要别的吗？提前致谢。
关于单元测试框架，主要有两个：jUnit和TestNG。两者都有各自的优势，并且都具有同等的性能。jUnit 的主要优点是（在我看来）它默认包含一个 Eclipse 插件，从而可以轻松调用测试。
关于模拟框架，我认为它们不是您的测试方法的必需部分。当然它们很有用，但它们解决了一个特定目的：测试行为（与测试接口相反 - jUnit 允许什么。使用模拟框架，您可以测试特定类如何实现特定接口。你会需要它？显然。你会先需要它吗？我不知道。
关于规则，我发现唯一有用的规则很简单（一如既往）：“总是测试至少破坏一次的代码。”。考虑您的错误跟踪器。每次遇到错误时，都必须进行单元测试以确保没有回归。在我看来，这是获得高质量代码的更快方法。
关于花哨且高效的输出，我可以向您推荐足够的安装持续集成服务器（显然是Hudson）。每次提交代码时，它将运行您的所有测试套件，以确保没有副作用。它将生成显示测试运行次数的图表，依此类推。它还可以集成代码覆盖工具和图表。这个持续集成服务器真的会很快成为你的测试伙伴。
如果您还没有这样做，请阅读Michael Feathers的《有效使用遗留代码》。
有什么工具可以为项目经理生成漂亮的输出来讨好？
当心。用于显示单元测试计数、覆盖率、代码质量指标、行数、签入计数等指标的精美工具在某些项目经理手中可能很危险。项目经理（不了解软件开发的现实）可能会沉迷于指标，而没有意识到：
他们没有给出项目健康和进展的真实情况，并且
他们可以完全错误地描述单个团队成员的表现。
您可能会遇到愚蠢的情况，即经理向开发人员发出信息，他们应该（例如）尝试在根本没有保证的情况下为代码实现最大的单元测试覆盖率。时间花在无意义的工作上，重要的工作没有完成，错过了最后期限。
应该设置的任何规则 - 代码覆盖率，或确保它是单元测试而不是集成测试。
代码覆盖对于可能脆弱/有缺陷的部分代码更为重要。不要强制要求任何基准覆盖级别。
单元测试与集成测试取决于您正在构建的系统的性质和复杂性。
事后添加大量单元级测试可能是浪费时间。仅应针对被确定为有问题/需要维护工作的班级进行。
事后添加集成级别测试很有用，尤其是在项目原始开发人员不再存在的情况下。一个体面的集成测试套件有助于增强您对某些更改不会破坏重要系统功能的信心。但这需要明智地进行。测试网站外观和感觉的第 N 级的测试套件可能是维护的噩梦......并且会阻碍进步。
我一直在为 C++ 项目改造单元测试，这并不令人愉快。
我做的第一件事是确定大部分“动作”发生在哪里。然后使用它开始对可以轻松测试的功能进行单元测试。
然后，一旦你有了更简单的方法，你就可以开始考虑病毒式地扩展覆盖范围——攻击依赖较少的函数，在调试器中运行它们几次，看看传入了什么值，然后用这些值编写单元测试确保你不会破坏任何东西。
不要指望快速修复 - 需要 3 周（每天 6 小时，每周 5 天）才能获得 20% 的覆盖率，但代码在该代码中花费了 80% 的时间，所以我认为时间花得很好并且已经发现相当多的错误。
关于测试覆盖率，我认为当您将单元测试引入现有项目时，开始设置覆盖率预期还为时过早。您应该首先确保您实际上可以集成测试框架并从覆盖工具中获取报告。完成后，您可以开始监控覆盖率，然后您可以考虑目标。