有没有工具可以生成漂亮的输出，让项目经理奉承？
要小心。一个用来显示单元测试计数、覆盖率、代码质量度量、行数、签入计数等度量的花哨工具在某些项目经理手中可能是危险的 *。一个项目经理（他不接触软件开发的现实）可能会沉迷于度量，而没有意识到：

• 它们并不能真实的地给予项目的健康状况和进展情况，
• 他们会对团队成员的表现给予一个完全错误的印象。

你可能会遇到一些愚蠢的情况，经理告诉开发人员他们应该（例如）努力实现代码的最大单元测试覆盖率，而这是根本不必要的。时间被花在无意义的工作上，重要的工作没有完成，错过了最后期限。
任何应该设置的规则-代码覆盖率，或者确保它是单元测试而不是集成测试。

• 代码覆盖率对于代码中可能存在脆弱/错误的部分更为重要。可接受的覆盖率级别应反映这一点。
• 单元测试与集成测试取决于您正在构建的系统的性质和复杂性。
• 在事实发生后添加大量的单元级测试可能是浪费时间。它应该只对被确定为有问题/需要维护工作的类进行。
• 在事后添加集成级测试是有用的，特别是当项目的原始开发者已经不在的时候。一个好的集成测试套件有助于增加你的信心，一些改变不会破坏重要的系统功能。但是这需要明智地进行。一个测试网站外观和感觉的测试套件可能是一个噩梦，维护起来......并且阻碍进步。

关于单元测试框架，主要有两个：jUnit和TestNG。两者都有各自的优点，而且两者的性能都是一样的。jUnit的主要优点（在我看来）是它默认包含了一个Eclipse插件，允许轻松的测试调用。
关于mocking框架，我并不认为它们是测试方法的必需部分。当然，它们很有用，但是它们解决了一个特定的目的：测试一个行为（与测试一个接口相反--jUnit允许的。通过模拟框架，你可以测试一个特定的类如何实现一个特定的接口。你需要它吗？当然。你首先需要它吗？我不知道。
关于规则，我发现唯一有用的规则很简单（一如既往）：“总是测试至少有一次错误的代码。"。考虑一下你的bug跟踪器。每次遇到bug，都必须有一个单元测试来确保没有回归。在我看来，这是获得高质量代码的更快方法。
考虑到花哨和有效的输出，我可以建议你安装一个连续的集成服务器（显然是Hudson）。它会在每次提交代码时运行所有的测试套件，以确保没有副作用。它会生成图表，显示测试运行的次数，和图形，这个持续集成服务器将真正成为您快速测试的好伙伴。

这是一个复杂的问题，所以我们在$work的实践中有几点注意事项：

• JUnit确实仍然是标准，大多数文档和文献都讨论JUnit。
• Mockito似乎是Java模拟领域的星星，尽管我们仍然使用JMock，并认为它能够满足我们的需要。
• 我们使用EclEmma Eclipse插件来检查我们的测试覆盖率，并且喜欢它。

如果您还没有这样做，请逐个读取Michael Feathers。

我一直在对一个C++项目的单元测试进行改进，这并不令人愉快。
我做的第一件事是确定大多数“操作”发生的地方。然后用它开始对那些容易测试的函数进行单元测试。
一旦你有了更简单的函数，你就可以开始考虑病毒式地扩展覆盖范围--攻击那些依赖性更少的函数，在调试器中运行几次，看看传入了什么值，然后用这些值编写单元测试，以确保你不会破坏任何东西。
不要指望一个快速修复-它花了3个星期（6小时天，每周5天），以获得20%的覆盖率，但代码花了80%的时间在该代码，所以我认为这是时间花得很好，并已发现了相当多的错误。

关于测试覆盖率，我认为当你在一个现有的项目中引入单元测试时，现在就开始设置覆盖率期望值还为时过早。你应该从确保你实际上可以集成测试框架并从覆盖率工具中获得报告开始。一旦你完成了这些，你就可以开始监控覆盖率，然后你就可以考虑目标了。