单元测试是绩效评估的一部分？-InfoQ

本文要点

如果确保开发人员正在投身于流行的开发实践

如果区分开好的单元测试和差的单元测试

单元测试的好处

如何度量单元测试，既要定量也要定性

好的绩效评估看起来是什么样的

绩效评估对雇主和雇员都有好处。它是个针对未来工作绩效提建议、识别指标和设置预期的时机。它还是个坦诚交流绩效以及可以如何提升绩效的时机，而这种交流往往都很缺乏。不断进行绩效讨论有助于避免未来出现严重的问题。

但是，针对软件开发人员和你的开发组织的绩效评估看起来应该是什么样子的呢？

没错，你已经实现了迭代，甚至为单元测试引入了培训机制。但是，除非你换掉全部研发人员和顶层敏捷专家（只是没有足够的人才供得上），否则你就需要确保你的开发人员掌握了流行的开发实践，比如单元测试。

怎么做呢？通过频繁、每年四次的绩效评估来进行绩效度量。通过把单元测试纳入到绩效评估中，表彰那些做单元测试的开发人员，以及确保预期清晰一致的管理和研发团队。

年度绩效评估已经受到了许多的非议，许多公司正在想要废弃它。对于了解、改变和改进来说，一年仅仅一次是不够的。年度绩效评估不是敏捷的！

但是不管怎样，都要经常评估团队的工作，确保你所度量的开发人员正在进行专业的编程工作，其中包括单元测试。

单元测试可达成几个重要的业务目标：质量改进、具有测试遗留代码的能力、开发人员在最新的代码和最好的方法论之上开展工作，是的，好的单元测试甚至会增加开发人员的积极性。

编写好的不会因单个代码变更造成损坏的单元测试并不难，遵循以下简单实践即可完成：

单元测试应该是自动化的

单元测试不应该依赖于环境设置、其他测试、完成顺序或运行的特定顺序。运行同一单元测试 1000 次应该返回同一结果。

使用静态变量、外部数据（比如注册表、数据库）或环境设置等全局状态可能会导致测试间的“泄漏”。测试运行的顺序应该不影响测试的结果，所以在多个测试运行之间应确保适当地初始化和清理每个全局状态，或从根本上避免去使用它。

清楚你正在测什么

测试特定场景或对象的每个方面是没有错的。问题是开发人员往往喜欢把几个这类的测试塞进一个单独的方法里，创建一个非常复杂而脆弱的“单元测试”。

我找到一个小技巧，就是把场景测试和预期的结果作为测试方法名称的一部分。如果开发人员这么命名他的测试时觉得有问题，就意味着她不确信正被测试的是什么。

只测试一件事还有额外的好处，那就是测试更加可读。当一个简单的测试失败时，比冗长复杂的测试更容易找出失败的原因并修复它。

专注于测试范围

测试范围与它的脆弱程度之间有着直接的关系。大多数测试有一个待测对象，它作为该测试的一部分响应或调用其他对象。这些外部依赖的内部工作方式对这个测试来说并不重要，可以予以伪造。使用隔离（也称做模拟），以便这些测试不必初始化和设置这些会用到但不是实际被测试的对象，这样可以使其中的对象变更时不会影响到测试。

避免过于规格化

通过设立每个单独的对象并测试每个单独的方面，创建良好定义的、可控的和严谨的测试，它们能在测试时遵循精确处理流程，这是件非常具有吸引力的事。问题是这么做使其与待测场景“紧紧锁定”，即使不会对最终结果产生影响的变更也无法进行了。

最终我们要的是可维护的代码。可维护的代码即可变更的代码。且不说按时完成任务了，你还可以度量代码的可维护性是多少，做这件事的最佳方式就是通过单元测试进行度量。

通过度量你的代码的可维护性是多少，包括每个开发人员通过单元测试为这个重要质量 KPI 所做的贡献，当下个开发人员到来时，提速将是轻而易举之事。

你正在评估团队为质量做了多少贡献吗？

我们现在都清楚，单元测试会提升软件的质量。通过单元测试，技术债会降低，所发布代码的缺陷会降低。开发人员对他们的代码更具信心，因为测试人员能帮他们了解到什么运转正常什么运转不正常。它还能帮开发人员回溯和修复遗留代码。

如果你不度量它，它就不会改进。我们看到过很多不写单元测试的团队，因为他们不评估它，而且不会根据它来升职。没有包括单元测试在内的绩效评估，开发质量会受到损害，你的代码将难以维护。开发人员很难从一个项目换到另一个项目中。

好的绩效评估有定量和定性的指标。所以，在你的员工激励计划和绩效评估中对它是否有所体现呢？毕竟，如果他们不清楚你对单元测试的认可和奖励，在严格要求期一过恐怕就将偷工减料了。

通过包括对每个开发人员的职责（有些人更专注于纠错，还有些人涉及的是遗留代码，而有些人正在使用简单的框架开发全新的特性）进行适当的定性和定量度量，你可以鼓励好的软件开发实践。这有助于你的团队，确保你们可以发布高质量的软件，且更加快速。

单元测试应如何正式地包含在评估之中？

你可以考虑以下度量：

定量的

定性的

新的或变更的测试数量
测试覆盖率
新代码
vs
遗留代码
被测试报告的缺陷
客户抱怨
缺陷率
对单元测试的开发心态
代码复杂度
持续学习
导师制
工作的质量

如今，对绩效评估有些非议。敏捷开发不仅仅是一组实践，更是一种心态。当它变成一纸检查表而不是一个流程时，它的失败率就已经增高了。可能有些单元测试就不会增加商业价值，比如测试不相干的代码，因此增加代码覆盖率也不会增加价值。

因为它是好的实践，而不是因为尖头发的上司（译注：pointy-haired boss 是 Scott Adams 创造的一个形象）想要提交一份度量报告，所以最好的开发人员才想要做些什么，只关注于度量而不是目标的绩效评估在管理中很常见，可是它并没有多大效果。

因此，好的绩效评估应关注于商业目标和打开沟通交流的渠道。

很幸运，甚至大型公司现在也正在抛弃年度绩效评估，而采用更频繁的自由形式的反馈。具有定性和定量目标的频繁反馈是个好的实践。

频繁评估还有助于带你的组织接近理想的敏捷。敏捷宣言价值观“响应变化胜过遵循计划”以及 Scrum 项目管理所谓的快速优先、频繁反馈早已人尽皆知。

自由形式的反馈还鼓励专注于商业目标而不是各种度量。

但是不论你的评估有多么频繁，是周、月、季度还是年度，只要它们与奖金和升职有关，单元测试就应该成为其中的一部分。

我们举一个例子，看看绩效评估大概看起来是什么样子的：

业务目标：编写持久、健壮的代码

Susan Bar 一直都提倡在团队内部开展单元测试。她的代码有着良好的覆盖率，针对复杂的问题我们的单元测试仪表盘会给出警示。她发现了 10% 以上更关键的问题，否则这些就会发给质保人员，使发布时间推迟。她还测试已有和遗留的代码，这有助于其他开发人员持续编写代码。这有助于降低未来增加特性时所需的时间。

把单元测试视为绩效评估中重要的 KPI 是对员工的认可，表示你重视代码质量和流行的软件方法论。把单元测试涵盖到绩效评估中会让你获得更好的质量、更积极的员工和更好的、缺陷更少的代码。所有这些正在让你实现敏捷理想：更好的软件、更快。

单元测试不能简单地看成绩效评估上的一条线。你需要把它看做贯穿整个开发组织的一些东西：从提供最好的工具（比如‘ Typemock Suggest ’ 建议的单元测试），到像 Scrum 之类的工作流以及软件技术和极限编程之类的开发实践，确保单元测试是日常工作天然的一部分，与整个软件工程组织良好地集成在一起，包括 DevOps 和质保。

采用这种方式，你的绩效评估将更加自然，你的团队将不会去过虑他们的评估，而是想要成为更好的程序员。