测试覆盖率下降，并且很好（简短，已读）

卡尔·古斯塔夫·荣格（Carl Gustav Jung）的同步性概念表示，如果事件在没有因果关系的情况下发生，但似乎有意义地关联，则它们是“有意义的巧合”。 最近发生在我身上的这件事与一些请求有关。 我正在处理一个FOSS项目，并且创建了一个请求请求，CI服务器拒绝了该请求，原因是不能合并降低测试覆盖率的请求。 我知道为什么代码覆盖率降低了，我知道这不仅不错，而且实际上还不错。 我可以说服维护人员在这种情况下跳过这种情况。 几天后，一个初级开发人员告诉我，出于完全相同的原因，在一个完全无关的项目中，他的请求请求被拒绝。 他向首席开发人员解释了为什么可以减少代码覆盖率，但是最后，他们要求他创建一些新的测试。 他是大三。 在连续两天中发生同一件事使我感到这可能是有意义的，也许值得一提。

但是，如何减少代码覆盖率却又很好呢？

假定您有一个简单的程序，该程序具有100 LOC（代码行）。 测试涵盖了50个LOC，而其他50个没有。 代码覆盖率为50％。

您修改代码并重构一个方法，该方法最初为20 LOC，测试覆盖100％，结果为10 LOC，原始测试覆盖100％。 仅仅是旧代码的设计错误和冗余（级别5，程序员诱发的冗余）。 现在覆盖率是100％* 40/90 = 44.44％。

这有问题吗？ 纯粹的数字44.44％本身实际上是一个问题，而重构之前的50％就是一个问题。 但是，将代码简化和缩短以及覆盖率降低这一事实绝对不是问题。

您是否应该从CI服务器构建过程中删除此规则，即拉取请求一定不能减少相对测试代码的覆盖范围？ 当然不是。 与我上面描述的情况相比，还有更多的情况是懒惰的或不够仔细的开发人员错过了一些测试。 覆盖范围的减少很好地表明了拉取请求的质量可能不高。 虽然有例外，但必须加以处理。

如果有这样的拉取请求，您是否应该命令初级用户编写一些其他测试来增加覆盖率，尽管这些测试与实际更改完全无关？ 我不知道。 我当然不会那样做。 我会接受将请求作为例外的拉出请求，然后如果需要的话，我会请初级学生创建更多测试。 但是这些完全无关。 仔细考虑一下，拒绝拉取请求可能是一个好主意。 毕竟，不仅必须对初中生进行有关编码和编程的教育，而且还应对他们与真正的混蛋老年人的工作方式进行教育。

翻译自: https://www.javacodegeeks.com/2019/09/test-coverage-decreased-and-it-is-good-short-read.html