Python 中防御性编程的单元测试和单元测试缺点

要了解并深入了解防御性编程的理论，请查看本系列的第一篇指南。

保护我们免受未来错误困扰的最后方法之一是不要忘记过去的错误。旧错误往往会再次潜入长期存在的代码库中。这通常是由于有人不理解为什么某些东西以特定方式编写，并将其删除以“清理”它。

这又提出了另一种情况，即另一种形式的可执行文档很有用。因此，当毫无戒心的开发人员更改某些代码或删除某些内容时，就会有运行的代码提醒他们犯了错误。

通常，人们在测试驱动开发的背景下遇到单元测试。这是一个很棒的概念，但在实践中，它往往有点过于乐观，难以理解（即客户现在想要代码）。不过，这个讨论是另一篇博客文章的内容。

在本指南中，我们将讨论如何使用单元测试来保护您免受未来和过去的错误的影响。可以将其视为将TDD测试概念反转为更实用且前期时间成本更低的东西。

我建议你在修复错误后再编写测试。请参阅此讨论以了解更多原因。

这有几个可能不太明显的目的：

当然，您添加了一条不错的提交消息，表明您如何修复了错误，但不要止步于此。您的提交消息和评论可能缺少以下内容：

• 您如何测试此修复？
• 什么具体情况导致了该错误？

这时，良好的单元测试就派上用场了。您已经知道如何测试错误了。（您在提交之前确实测试过，对吧？）因此，整理您测试的场景，让每个人都能从您的辛勤工作中受益。

单元测试是阐明所有内容并提供错误修复文档的绝佳场所。您不仅可以解释修复错误的方式和原因，还可以解释测试方法。如果错误再次出现，这些信息将非常有价值。

不要忘记，通过的测试可以作为错误所在位置的线索。

特定错误潜入代码库的情况并不少见。这种情况可能是由于需求变化、重构错误或任何其他情况而发生的。您可以通过为特定错误修复编写单元测试并记住运行测试来捕获回归。将单元测试视为您自己免于以后可能再次注入错误的免责卡。

单元测试的主要缺点是很容易忘记运行它们。这只是测试不能直接与代码一起定位的副产品。可以通过使用Travis CI之类的东西进行持续集成并自动化测试来减轻这一缺点。

另一个缺点是单元测试通常只在其自己的测试环境中执行，这是一个没有真实用户的模拟环境。

这种开发风格很难分类，不幸的是，没有任何固定的规则来说明何时使用什么。所以，我鼓励你记住这些指导原则。

这些指导方针将导致思维方式发生微妙的变化。思维方式的改变很重要，而不是工具和机制本身。最终，你会因为过度使用断言或日志而犯一些错误，并开始形成自己的风格。此外，每个项目的要求都不同，因此学习所有工具并以适合你情况的方式组合它们很重要。