写过代码的同学对 debug 的痛苦应该深有体会,debug 的时间往往远远超过实际编写代码的时间,最终却发现只是一个意料之外的微不足道的错误导致了 bug。过了一段时间,重新使用这段代码的时候,又出现了新的 bug, 但偏偏还不能怪别人,毕竟是自己写的代码,血压上来了.jpg。程序说变量未定义那就真的是未定义,说变量类型不对那就是真的不对,总不能砸电脑吧。
有没有什么办法可以减少和规避 bug 呢?本期的主题「单元测试」就是一种方法。一段代码在运行时出现 bug,意味着 bug 可能出现在代码任何地方。代码越长,定位 bug 越困难,反过来说,代码越短,定位 bug 越容易。如果尽量保证每一小段代码都能正确执行其功能,那么它们组装起来也应该能正常工作。这里的小段代码通常指单个函数,它们组装起来,就是整个程序。单元测试要做的事,就是尽量保证每个函数都能正确执行其功能。
Notebook 上手实践
本期 Notebook 将从实际情形出发,从读者熟悉的事物引出单元测试,介绍单元测试的含义和基本用法。我们并非试图告诉读者所有关于单元测试的细节,而是希望读者从整体上理解做单元测试的意义和单元测试的本质。请放轻松,这并非艰深的话题,不需要额外的经验,只要你写过代码,就完全可以将本期作为电子榨菜。如果你对单元测试感到好奇,不妨亲自打开 Notebook 试一试,希望你能从中收获新的知识。
欢迎大家来 Notebook 案例广场,获取更多有意思的实践~
感兴趣的同学也可以点击原文查看.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。