手动重现错误是好的！

但它很慢。真的很慢。

如果您每次都必须在 UI 中单击以重新创建错误，那么您将以次优的速度工作。发出 API 请求以复制错误也是如此。

当有复杂的逻辑在起作用时，我希望能够快速且经常地重放错误。

最好的调试策略是对重现步骤进行编码。

再生产

大多数错误工单都带有一组重现步骤。

给定特定的条件组合，您应该能够重现错误。一旦您知道如何重现错误，您就可以很好地解决它。

创建重现步骤并不总是那么容易！

但了解错误是如何发生的至关重要。如果您的目标不是创建可重现的步骤，那么您只是在没有策略的情况下疯狂地攻击问题。

最好首先关注可靠地重现错误。

更快的反馈

一旦可以重现错误，就不要只是手动重现它。

编码吧！

编写单元测试或设置脚本，以编程方式在代码中重现错误。

目标是创建一个可以重复运行的命令。我们想要快速的反馈，我们可以一遍又一遍地重现。

此步骤对于快速解决问题至关重要。

测试你的假设

解决棘手错误的方法是测试您的假设。

一旦您有了重现错误的编程方法，就可以开始测试错误代码的各个部分。

• 您期望在执行过程中的某些点有什么价值？
• 值是否按预期提交给数据库？
• 代码是否与其他服务交互？它们是否返回预期的响应？

当您可以运行和重新运行代码时，这些假设变得更容易测试。

通常，在以编程方式重现错误的过程中，您会发现一些东西。您将意识到目标代码的哪些区域没有按照您期望的方式响应。

单元测试是为了解决方案

始终为错误的解决方案编写单元测试！

我们无法编写没有错误的软件。我们是人类。会有错误。

但是，我们可以编写测试以确保代码不会再次以同样的方式中断。

您应该为您使用的每个功能编写测试。如果没有，您需要在您的工程组织中进行认真的对话。

当您修复错误时，应该始终对其进行测试。

如果您使用单元测试重现了错误，那么一旦该测试通过，您就完成了！双赢！

每日清单

需要更多有关调试、构建有价值的功能和发展您的开发人员职业的建议吗？

如果你喜欢我的文章，点赞，关注，转发！