前言:

这篇文章的目的, 不是要否定单元测试存在的价值、意义。而是要从产品的视角, 客观、正确的审视产品中已开发完成的单元测试, 对于产品开发的效率、产品的质量到底是能起到个正面提升的力量? 还是对产品质量的帮助是极其有限, 但却会拖累著开发的效率?

Hotspots 的分析将能使我们客观、正确的面对产品中已开发完成的单元测试; 客观、正确的:

  • 删除属于 “负债” 的单元测试; 对产品质量的帮助是极其有限, 但却会拖累著开发的效率。

 

本文:

Adam Thornhill 的算法模型中的 Hotspots, 代表的是产品中复杂度高并且是提交到配置库频率高的模块、文件。

Hotspots 是经由计算两个纬度的度量而获得的:

  • 模块、文件的代码行数; 代表著模块、文件的复杂度。
  • 模块、文件提交到配置库的频率; 代表著模块、文件的变更频率。
图一: Hotspots = f(复杂度, 变更频率)

 

 

 

 

 

 

 

 

 

如图二所示; 我们从 Hotspots 的分析, 获得了 Hotspots 文件的警告信号: 

  • 单元测试代码的行数 (图二中的蓝线), 从一开始就远多于产品代码的行数 (图二中的蓝线)
  • 当产品代码的行数随著时间的推移而增加时, 单元测试代码的行数却没有成对比性的增加。
  • 单元测试代码的复杂度的趋势 (图二中的橘线) 与产品代码复杂度的趋势 (图二中的橘线) 是以不同的模式在发生变化的。
图二: 从 Hotspots 的分析, 审视单元测试是负债? 还是资产?

 

 

从 Hotspots 的分析, 所获得的 Hotspots 文件的警告信号, 我们客观、正确的审视 Hotspots 文件的单元测试:

  • 单元测试代码行数变化的趋势、复杂度变化的趋势, 都与产品代码是完全不匹配、不平衡的。所以, 此 Hotspots 文件的单元测试, 基本上是已无法随著时间的推移、产品版本的演进, 而能保障 Hotspots 文件的质量的。
  • Hotspots 文件的单元测试无法保障 Hotspots 文件的质量, 但当 Hotspots 文件中的产品代码发生变更时, 开发人员却往往还需花费许多宝贵的开发时间, 去变更单元测试, 以使得在持续集成上的构建可顺利的完成。

在图二的例子中, Hotspots文件的单元测试已无法保障 Hotspots 文件的质量, 但, 却仍需开发人员花费时间、精力去进行变更、维护?!

所以, 从 Hotspots  的分析, 我们得到在图二的例子中的单元测试的真相:

图二的例子中的 Hotspots 文件的单元测试是 “负债”, 而不是资产。

毫无疑问的, 我们应该 “删除” 已属于 “负债” 的单元测试。

 

结论:

在敏捷开发中, 我们一直坚信著单元测试对提升、保障产品的质量是有著直接的助益的。但我们一直没法去客观、正确的分析单元测试代码与产品代码间的关系, 以致于我们只能根据主观上去做出结论:

  • 我们已开发完成的单元测试, 还在持续的提升、保障著产品的质量。

现在, 我们由 Hotspots 的分析, 我们可客观、正确的分析单元测试代码与产品代码间的关系, 看清单元测试的真相; 有信心的作出结论:

  • 所开发完成的单元测试到底是负债? 还是资产?    

 

 

相关的阅读:

产品中的 Hotspots: 基于配置库中代码所隐藏的开发者行为, 高效的提升产品的质量与开发的效率

高效、低成本的付清技术债务; 在 200,000 行代码的模块里, 找到最值得优先关注的 180 行代码

开发人员提交代码行为的背后, 隐藏著会让我们大为惊讶的故事

Proximity: 付清技术债务; 不消除重复代码, 却能提升产品开发的效率、质量

2 thoughts on “别再傻傻的写单元测试了; Hotspots 告诉我们单元测试的真相: 单元测试是负债? 还是资产?”

  1. 单元测试代码行数变化的趋势、复杂度变化的趋势, 都与产品代码是完全不匹配、不平衡的。所以, 此 Hotspots 文件的单元测试, 基本上是已无法随著时间的推移、产品版本的演进, 而能保障 Hotspots 文件的质量的。
    ———
    也许错误的实践方式得到了这种结论。

    1. 是的。但什么原因造成已不重要了。重要的是:图二中的这个单元测试已无法保障 Hotspots 文件的质量了。另外, 如文章的开头所说, 这篇文章不是在说单元测试的这个实践有问题, 而是在说图二中的这个单元测试有问题。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据