0
0
前言:
这篇文章的目的, 不是要否定单元测试存在的价值、意义。而是要从产品的视角, 客观、正确的审视产品中已开发完成的单元测试, 对于产品开发的效率、产品的质量到底是能起到个正面提升的力量? 还是对产品质量的帮助是极其有限, 但却会拖累著开发的效率?
Hotspots 的分析将能使我们客观、正确的面对产品中已开发完成的单元测试; 客观、正确的:
- 删除属于 “负债” 的单元测试; 对产品质量的帮助是极其有限, 但却会拖累著开发的效率。
负债的单元测试:
Adam Thornhill 的算法模型中的 Hotspots, 代表的是产品中复杂度高并且是提交到配置库频率高的模块、文件。
Hotspots 是经由计算两个纬度的度量而获得的:
- 模块、文件的代码行数; 代表著模块、文件的复杂度。
- 模块、文件提交到配置库的频率; 代表著模块、文件的变更频率。
如图二所示; 我们从 Hotspots 的分析, 获得了 Hotspots 文件的警告信号:
- 单元测试代码的行数 (图二中的蓝线), 从一开始就远多于产品代码的行数 (图二中的蓝线)。
- 当产品代码的行数随著时间的推移而增加时, 单元测试代码的行数却没有成对比性的增加。
- 单元测试代码的复杂度的趋势 (图二中的橘线) 与产品代码复杂度的趋势 (图二中的橘线) 是以不同的模式在发生变化的。
从 Hotspots 的分析, 所获得的 Hotspots 文件的警告信号, 我们客观、正确的审视 Hotspots 文件的单元测试:
- 单元测试代码行数变化的趋势、复杂度变化的趋势, 都与产品代码是完全不匹配、不平衡的。所以, 此 Hotspots 文件的单元测试, 基本上是已无法随著时间的推移、产品版本的演进, 而能保障 Hotspots 文件的质量的。
- Hotspots 文件的单元测试无法保障 Hotspots 文件的质量, 但当 Hotspots 文件中的产品代码发生变更时, 开发人员却往往还需花费许多宝贵的开发时间, 去变更单元测试, 以使得在持续集成上的构建可顺利的完成。
在图二的例子中, Hotspots文件的单元测试已无法保障 Hotspots 文件的质量, 但, 却仍需开发人员花费时间、精力去进行变更、维护?!
所以, 从 Hotspots 的分析, 我们得到在图二的例子中的单元测试的真相:
图二的例子中的 Hotspots 文件的单元测试是 “负债”, 而不是资产。
毫无疑问的, 我们应该 “删除” 已属于 “负债” 的单元测试。
结论:
在敏捷开发中, 我们一直坚信著单元测试对提升、保障产品的质量是有著直接的助益的。但我们一直没法去客观、正确的分析单元测试代码与产品代码间的关系, 以致于我们只能根据主观上去做出结论:
- 我们已开发完成的单元测试, 还在持续的提升、保障著产品的质量。
现在, 我们由 Hotspots 的分析, 我们可客观、正确的分析单元测试代码与产品代码间的关系, 看清单元测试的真相; 有信心的作出结论：
- 所开发完成的单元测试到底是负债? 还是资产?
相关的阅读:
产品中的 Hotspots: 基于配置库中代码所隐藏的开发者行为, 高效的提升产品的质量与开发的效率
高效、低成本的付清技术债务; 在 200,000 行代码的模块里, 找到最值得优先关注的 180 行代码
Proximity: 付清技术债务; 不消除重复代码, 却能提升产品开发的效率、质量
