测试驱动的代码审查

资料来源： Wikimedia

一年前，我与最好的朋友Alex进行了有趣的代码审查讨论。 他说，在进行代码审查时，他总是从测试开始 。 他使用此技术来了解代码的实际功能，行为方式以及所涵盖的功能。

在检查了测试之后，他接着继续检查生产代码。 生产代码应该是有意义的，并遵循团队设定的原则/准则和模式（团队用“干净代码”表示的所有含义），这样每个人都可以遵循。

当您要实现功能时，可以将单个需求转换为用例。 您将单个用例转换为测试用例。 您可以在生产代码中实现这些测试用例。

如果您正在练习TDD，那么您将遵循TDD的三定律 。 这三个定律是：

• 在编写任何生产代码之前，必须编写失败的测试。
• 您编写的测试不得超过失败或无法编译的数量。
• 您编写的生产代码不得超过足以使当前失败的测试通过的代码。

这里真正有趣的是第三定律，因为它意味着如果测试通过，则不允许添加更多的生产代码，如果要添加更多的代码，则必须添加更多的测试用例。 换句话说，您的生产代码仅覆盖测试用例描述的内容。 只需查看需求并对照测试用例对它们进行检查，您就可以很好地理解实现的形式，实现的功能以及开发人员是否省略了任何用例并且不满足需求。

代码的行为受测试用例的限制

由于测试是API的第一个客户端，因此它们可以帮助您暴露设计问题，例如封装问题或组件之间的紧密耦合。

如果测试模拟了许多组件，那么您需要检查是否违反了封装，以及是否可以将其中某些组件设置为包保护或私有的。 封装是最重要的OOP概念之一，但也是开发人员最常使用的概念。

如果测试花费太多时间来模拟单个对象的方法调用链，那么您可以肯定地确定违反了Demeter法则 。 如果违反了Demeter法则，那么您可以确定该代码存在封装问题。 但是我知道，即使不看代码，我也只是看测试的结构就知道。

此外，您可以猜测开发人员没有实践TDD，因为测试对实现的内部知识了解太多。 只有在编写生产代码之后编写测试，才可能发生这种情况。

如果您知道测试是在实现之后编写的，则需要检查生产代码是否包含隐藏的功能，并且没有描述这些功能的测试。 这确实很糟糕，您不能让它发生，因为您将对测试套件失去信任。 提交该代码几个月后的一天，您将对其进行重构，并且由于没有描述该功能的测试用例，因此可以删除整个功能而无需注意。 这真是太糟糕了！

顺便说一句，测试也是代码

测试是您唯一拥有消除更改生产代码的担心的工具。 随着代码复杂度的增加（无论是否偶然），您都将重构代码，并且测试可以确保代码的行为相同。 马丁·福勒 （ Martin Fowler）有一本很棒的书叫 您应该阅读“重构：改善现有代码的设计” ！

因此，请花费相同或更多的时间来确保您的测试始终处于良好状态。 您需要进行代码审查并重构测试。 测试应遵循与生产代码相同的标准。

进一步阅读

1. TDD的周期
2. 微服务时代的得墨meter耳定律
3. 团队文化的重要性
4. 重构：改进 Martin Fowler和Kent Beck 的现有代码设计

From: https://hackernoon.com/test-driven-code-review-3f05f6cee400