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