【发布时间】：2023-03-30 10:50:01
【问题描述】：
场景：一个团队使用某种 SCM 处理 Java/Maven/JUnit 项目。我们希望增加测试覆盖率，这意味着所有开发人员都应该更深入地测试代码。使用 SonarQube 之类的工具来衡量整体测试覆盖率的改进很容易，但您需要每个开发人员都这样做，以便能够识别异常值：测试覆盖率最高的工程师和覆盖率最差的工程师。
您如何回答“开发人员 X 在上个月修改的代码的测试覆盖率是多少？”这个问题？是否有更容易遵循的替代、近似测量？
【问题讨论】：
-
理论上应该是可以的，你可以使用SCM的
blame函数来判断哪些行被哪个开发者修改，并与逐行覆盖率报告进行比较。但这是个好主意吗？除非您的团队很大，否则我认为不会。这表明缺乏信任，虽然有些人可能会背叛这种信任，但你最好的开发人员会感到被冒犯。更好的代理可能是分析实际的错误，检查它们是否来自未发现的代码，如果是，谁是罪魁祸首。如果这件事一直发生在同一个人身上，请和他们说悄悄话。 -
在我看来，如果你需要这样的东西，你的工作文化已经存在很大问题。你想要的是一个有这种感觉并共同为项目承担全部责任的团队。你想做的事会促进一种责备的文化。
-
@AndréStannek 好点子，与其专注于谁做的，不如鼓励人们为甚至不是“他们的”的代码编写单元测试。
-
@biziclop 你的
isn't even "theirs"让我补充一点：阅读集体代码所有权/共享代码:-) -
虽然我不赞成将羞辱/指责作为一种激励手段，但我们在这里使用 JaCoCo 和 ELCEmma + 在我们的夜间构建中使用最低代码覆盖率百分比来强制执行单元测试覆盖率。这有点痛苦，决定适当的代码覆盖级别不是一件容易的事，但它有助于发现错误，并总体上促进单元测试。我们还通过使用 CI 游戏为其添加了一些乐趣：wiki.jenkins-ci.org/display/JENKINS/… 至少让事情变得有趣。
标签： java maven junit code-coverage sonarqube