测试影响分析

□ 总结

PHPUnit应能够确定哪些测试可能因测试中代码的更改而受到影响,并提出只进行这些测试。

这所需要的信息已经存在于 PHP Unit 中: 当收集代码覆盖时, PHP Unit 确切知道每个执行的单个测试的源文件 。 今天,知识只用于编制报道报告,在运行结束时被抛弃。 它不停地回答一个问题开发者问:“我改变了这个文件,我需要运行什么?”

□动机

测试套房越大,有时实际使用越少。

一个需要10分钟的套房不是在每次改变之后运行;它是在犯罪之前运行,或者在推前运行,或者在CI投诉之前根本不运行. 单位测试中提供的反馈回路会被拉长,直到它不再是一个回路. 开发者通过手来围绕这个:运行一个单一的测试课,猜测出一个"--filter"模式,记得哪个目录"可能"覆盖了他们所接触的东西. 这些猜想是快的,它们往往是错误的,足以影响和错过同样行使已改变的线的三层外的试验。

PHPUnit比开发者更有能力回答这个问题,因为它观察了每个测试实际执行的,而不是假设它执行的.

这个想法来自哪里

这个想法是古老的,经过了很好的研究,在名称回归测试选择之下. Gregg Rothermel和Mary Jean Harrold在1990年代中将其形式化,并赋予了这个领域仍然最重要的财产:选择技术在选择每一个可能暴露变化带来的过错的测试时都称为安全. 他们的技术通过比较变化前后的控制流图而实现了这一点. 从那时起,一切都是一种交易 一种技术是多么安全 和它是如何便宜运行。

"测试影响分析"这个名称出自工业工具化而非文献. 微软在"Visual Studio 2010"中以该名称运出了一个功能,而保罗·哈曼特的2017年文章"测试影响分析的崛起"(https://martinfowler.com/articles/rise-test-impact-analysis.html)则将其推广使用.

之所以实际,是因为降低了决议的效力。 Ekstazi ([ISSTA 2015] (https://dl.acm.org/doi/10.1145/2771783.2771784))显示,在进行测试时动态观测到的文件颗粒的跟踪依赖性足够粗糙,可以便宜地收集并精确到足够有用,这是提案假设的颗粒性. 由Meta的预测测试选择起于2018年的一个不同分支,完全降低了依赖性跟踪,并使用机器学习从历史运行数据中预测. 这是一个不同的特征,不是这里建议的那样。

大多数生态系统现在都在这个空间里有些东西, 无论是建在... . . . . . . .