应该在单元测试之前或之后执行代码审查

我正在与我的同事讨论何时执行代码审查-在单元测试之前或之后。最佳做法是什么？

我们可能需要考虑的一些因素（可能还有更多）：

• 代码更改的大小-较大的更改意味着代码审查将导致更多更改。如果这些更改要大得多（如果UT在代码审查之前），则需要再次重复大多数UT。
• 进行单元测试所需的时间
• 是新功能还是错误修复

在进行代码审查之前，您应该始终进行单元测试，这就是为什么

1. 如果您的代码以某种可能会被单元测试捕获的方式破坏，那么您将使其他开发人员参与到红色/绿色/重构周期中，从而浪费了他们的时间。
2. 测试向其他开发人员显示了代码的预期用途，从而使代码更易于查看。
3. 如果您缺少测试用例或测试无法正常工作，则应将测试以及所测试的代码一起进行检查。
4. 测试和代码审查往往会发现不同的问题，而发现的问题几乎没有重叠。当审阅者发现问题时，单元测试不会因必须重新测试代码而烦恼，开发人员会感到烦恼，并且第二次可能做得不好。

可能还有其他原因，但那些是我亲眼所见并在3个不同的团队/公司中实施代码审查实践的原因。

编辑 当然，以上是针对代码检查是软件开发过程中的一步（无论是瀑布式还是敏捷式）的时代。如果您正在处理特别大的代码或困难的代码部分，请随时关注它。

代码审查适用于代码“完成”的情况。

在我的组织中，我们对“完成”的定义包括单元测试（我们针对TDD），因此代码审查属于完整代码-完整代码包括测试。

另外，测试需要检查和重构，因此将它们作为代码检查的一部分是有意义的。

测试应被视为要审查的代码的一部分。因此，在测试完成后复查是有意义的。

确保也检查了测试。对于那些不熟悉单元测试的人来说，这是至关重要的。

确保您的团队了解依赖注入，隔离框架，模拟与存根，接缝，交互与基于状态的测试以及集成与单元测试。

您无需实现上述主题，但您应该了解它们。

好，

这取决于您所说的“单元测试”的含义。

如果它是TDD风格的单元测试，那是没有意义的，因为您在编写代码时就编写了测试。没有事后案例，在这种情况下您可以不断提高代码质量：重构...

和

如果它是经典的“单元测试”（无论我不知道是什么意思，但是我指的是在编写代码后进行测试，并且通常由其他人完成），那么主要标准就是您对代码审查和单元测试性质的期望：您需要快速的反馈-进行审核并采取措施，并且没有自动化的单元测试，则必须等待单元测试。如果您想通过代码审查来确定成熟的问题，并逐步将解决方案应用于下一次迭代，则可以在单元测试之前进行...

但毕竟个人而言，对于代码审查而言，对我而言，之后或以后的单元测试不是真正的标准...

为什么我们要进行代码审查？对于代码质量...代替“质量控制”门，将质量注入您的软件开发过程环境中...

我倾向于说，让我们变得“敏捷” ...不要等到代码完成后再进行快速的非正式代码审查：确实有一些开发人员可以与他们一起讨论主题，代码+测试阶段结束... 但是

当涉及到真正的新主题（全新功能，近距离研究，对团队来说是全新的东西）时，请尽早进行代码审查，不要浪费时间：让同事不时看一下：隔离是重要的因素在这种情况下失败。

如果开发人员还是团队的新手，请尽早（可能经常）检查代码。

顺便说一下，单元测试也需要代码审查。