Python 中防御性编程的单元测试和单元测试缺点
介绍
要了解并深入了解防御性编程的理论,请查看本系列的第一篇指南。
单元测试
保护我们免受未来错误困扰的最后方法之一是不要忘记过去的错误。旧错误往往会再次潜入长期存在的代码库中。这通常是由于有人不理解为什么某些东西以特定方式编写,并将其删除以“清理”它。
这又提出了另一种情况,即另一种形式的可执行文档很有用。因此,当毫无戒心的开发人员更改某些代码或删除某些内容时,就会有运行的代码提醒他们犯了错误。
通常,人们在测试驱动开发的背景下遇到单元测试。这是一个很棒的概念,但在实践中,它往往有点过于乐观,难以理解(即客户现在想要代码)。不过,这个讨论是另一篇博客文章的内容。
在本指南中,我们将讨论如何使用单元测试来保护您免受未来和过去的错误的影响。可以将其视为将TDD测试概念反转为更实用且前期时间成本更低的东西。
我建议你在修复错误后再编写测试。请参阅此讨论以了解更多原因。
这有几个可能不太明显的目的:
1. 完善错误修复文档
当然,您添加了一条不错的提交消息,表明您如何修复了错误,但不要止步于此。您的提交消息和评论可能缺少以下内容:
- 您如何测试此修复?
- 什么具体情况导致了该错误?
这时,良好的单元测试就派上用场了。您已经知道如何测试错误了。(您在提交之前确实测试过,对吧?)因此,整理您测试的场景,让每个人都能从您的辛勤工作中受益。
单元测试是阐明所有内容并提供错误修复文档的绝佳场所。您不仅可以解释修复错误的方式和原因,还可以解释测试方法。如果错误再次出现,这些信息将非常有价值。
不要忘记,通过的测试可以作为错误所在位置的线索。
2. 防止代码重复出现错误
特定错误潜入代码库的情况并不少见。这种情况可能是由于需求变化、重构错误或任何其他情况而发生的。您可以通过为特定错误修复编写单元测试并记住运行测试来捕获回归。将单元测试视为您自己免于以后可能再次注入错误的免责卡。
单元测试的缺点
单元测试的主要缺点是很容易忘记运行它们。这只是测试不能直接与代码一起定位的副产品。可以通过使用Travis CI之类的东西进行持续集成并自动化测试来减轻这一缺点。
另一个缺点是单元测试通常只在其自己的测试环境中执行,这是一个没有真实用户的模拟环境。
结论
免责声明:本内容来源于第三方作者授权、网友推荐或互联网整理,旨在为广大用户提供学习与参考之用。所有文本和图片版权归原创网站或作者本人所有,其观点并不代表本站立场。如有任何版权侵犯或转载不当之情况,请与我们取得联系,我们将尽快进行相关处理与修改。感谢您的理解与支持!
请先 登录后发表评论 ~