将单元测试引入现有项目

有没有什么工具可以为项目经理提供漂亮的输出?

小心。用于显示单元测试计数、覆盖率、代码质量度量、行计数、签入计数等度量的奇特工具可能很危险。 在一些项目经理手中 . 项目经理(不了解软件开发的实际情况)可能会沉迷于度量标准,并且无法意识到:

• 他们没有给出项目健康和进展的真实情况,以及

• 他们可以对每个团队成员的表现给出完全错误的描述。

你可能会遇到一些愚蠢的情况,在这种情况下,管理者会向开发人员传达这样的信息,即他们应该(例如)尝试为代码实现最大的单元测试覆盖率,而这是完全没有必要的。时间花在无意义的工作上,重要的工作没有完成,最后期限也没有完成。

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

• 对于代码中可能很脆弱/有缺陷的部分,代码覆盖率更为重要。不要要求任何基准覆盖级别。

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

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

• 在事实发生后添加集成级测试是有用的,特别是当项目的原始开发人员已经不在时。一个合适的集成测试套件有助于增强您的信心,即某些更改不会破坏重要的系统功能。但这需要明智地进行。测试一个网站外观和感觉的第n度的测试套件可能是维护网站的噩梦…阻碍进步。

关于单元测试框架,主要有两个:JUnit和TestNG。两者都有其独特的优势,而且都具有同等的性能。JUnit的主要优点是(在我看来)它的默认配置为Eclipse插件,允许简单的测试调用。

关于模拟框架,我不认为它们是测试方法的必需部分。当然,它们是有用的,但它们解决了一个特定的目的:测试一个行为(与测试一个接口相反——JUnit允许的行为)。使用模拟框架,您可以测试特定类如何实现特定接口。你需要吗?很明显。你先要吗?我不知道。

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

关于花哨和高效的输出,我可以向您推荐足够多的连续集成服务器。( Hudson 很明显。它将在每次提交代码时运行您的所有测试套件,以确保没有副作用。它将生成显示测试运行次数的图形,等等。它还可以集成代码覆盖工具和图形。这个持续集成服务器将真正成为您的测试伙伴。

这是一个复杂的问题,所以只需对$work的实践做几点说明:

• JUnit确实仍然是标准。大多数文档和文献都会讨论JUnit。
• Mockito 似乎是Java嘲讽中的新星,尽管我们仍然使用JMOCK,认为它对我们的需求很好。
• 我们使用 EclEmma 用于检查我们的测试覆盖率的Eclipse插件,并且喜欢它。

如果你还没有这样做,请阅读 Working Effectively with Legacy Code 通过 Michael Feathers .

我已经将单元测试改装成C++项目,这是不愉快的。

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

然后,一旦你有了更简单的方法,你就可以开始恶意地扩展覆盖范围——攻击那些依赖性更小的函数,在调试器中运行它们几次,看看传入了什么值,然后用这些值编写单元测试,以确保你不会破坏任何东西。

不要期望快速修复——需要3周(6小时,一周5天)才能获得20%的覆盖率,但代码将80%的时间花在代码上,所以我认为它花了很长时间,并且发现了不少错误。

关于测试覆盖率,我认为当您将单元测试引入到现有项目中时,开始设定覆盖率预期还为时过早。您应该首先确保实际上可以集成测试框架并从覆盖工具中获取报告。一旦你这样做了,你就可以开始监控覆盖率,以及 然后 你可以考虑目标。