代码审查是否涉及测试？

当您查看某人的拉/合并请求时，是否签出分支并运行构建？ 我通常不这样做，但是有些人这样做 。 它们的明显原因是：运行构建，甚至手动测试产品，有助于发现更重要的错误。 例如，仅查看源代码可能无法揭示出最近引入HTML / CSS的所有视觉缺陷。 最好检查分支，启动Apache，在Chrome中打开该站点，然后查看发生了什么问题。 然后，制作一个屏幕截图，将其附加到拉取请求中，然后将其返回给作者。 但是我不同意这一点，这就是原因。

为何女人杀死（2019），马克·樱桃（Marc Cherry）

讨论是不是新的，检查这和这对SO。 但是，似乎所有答案都没有抓住关键点。

众所周知，任何软件项目中都有两个相互冲突的角色 ：构造函数和析构函数，也称为程序员和测试人员。 程序员添加了新功能并修复了错误。 其结果是创建的功能数量：越多越好。 当测试人员破坏产品并报告错误时，他们应尽一切努力证明尚未准备好将产品交付给客户。 在某个时间点，团队（或管理层）决定战斗已经结束并且可以交付产品。

由于这种基本的冲突， 质量得以实现。

当代码通过合并管道时，程序员便完成了自己的任务：更改在他们的笔记本电脑上进行，单元测试在本地通过，静态分析没有问题，构建很干净，并且分支合并到了主干。 这是程序员停下来获得奖金的地方。

当测试人员设法在部署到暂存或生产环境中的产品中发现新缺陷时，测试人员便完成了自己的工作：发现，报告并接受项目中的错误。 这是测试人员停止并获得奖金的地方。

这是显而易见的。 如果不是，您可能想要阅读Glenford Myers撰写的《软件测试的艺术》或Yegor Bugayenko撰写的Code Ahead 。 您可能还想观看此视频 。

现在，在此冲突中，代码审查者的位置在哪里？

我认为代码审查是合并管道的一部分，它与单元测试，静态分析器，lint，覆盖率控制工具，变异测试器以及项目可能希望放入的所有其他项目一起使用，以使程序员的生活更加困难并且源代码的质量更高。 合并管道的目的是保护代码存储库免受程序员的攻击。

代码审阅者与linter或静态分析器没有什么不同：它们阻止具有错误代码的分支进入主干。 当他们封锁时，他们会说出原因。 当他们设法在分支机构中发现问题并对其进行解释时，他们的工作就完成了（类似于短毛猫）。 短绒猫在拒绝拉取请求时会准确地说出问题出在哪里，哪条线以及如何解决。 优秀的代码审查人员必须做到这一点：找到有问题的线路，解释问题，并提出解决方案。

这是必须向代码审阅者支付的费用：完成的审阅。

什么是完整的评论？ “一切都OK”听起来像是完整的评论吗？ 对于短毛绒-是的； 对于代码审阅者-不。 这个问题要好得多：“我发现了三个问题，对它们进行了解释，然后对它们进行辩论或解决。” 这就是代码审阅者的工作描述的声音：查找三个最关键的问题，进行解释，并确保它们已解决或正确争论。

审阅者如何发现这三个问题-取决于他们。 他们可以对代码进行外观检查或运行构建。 但是，当他们设法找到问题并确保代码作者理解它们并修复它们或说明它们不可修复（或不是问题）的原因时，仍将获得报酬。 目视检查代码很快，而检查分支并运行构建则要花费很多时间。 此外，在本地运行构建后发现的错误很难以代码查看格式进行解释。 与分支的作者进行的讨论将花费更长的时间，这意味着需要更多的时间来完成代码审阅，这意味着代码审阅者的效率较低。

我的观点是，聪明的代码审阅者不会这样做，因为这样做效率不高。 注意，不是因为他们不在乎，而是因为他们知道为项目做贡献的更好方法。 让我们面对现实吧，当我们面前的分支通过所有自动化检查（如林特和单元测试）时，仍然存在一些错误，我们只能通过执行代码才能重现这些错误，这对我们的自动化测试来说是不对的。 一个有效，负责和贪婪的代码审阅者不会向代码作者解释错误之处。 相反，将创建一个新的错误，以归咎于合并管道太弱。 而且，当然，这个新错误将得到回报。

因此，作为代码审阅者，您可以在本地与分支合作，对其进行测试并将发现的结果报告给作者。 但这将违反您的个人利益，对项目无益。 相反，您应该向项目抱怨自动化测试的质量低下，并搁置审核。 解决投诉后，测试将变得更强大，您将返回到复审，该复审将被合并管道而不是您拒绝。

在这种情况下，每个人都会取胜：管道变得更强大，您为报告的错误获得了额外的奖励，并且由于特定的可重复原因而拒绝了审核。

PS：此博客文章的想法由RobertSösemann提出。

翻译自: https://www.javacodegeeks.com/2019/12/does-code-review-involve-testing.html