寫過代碼的同學對 debug 的痛苦應該深有體會，debug 的時間往往遠遠超過實際編寫代碼的時間，最終卻發現只是一個意料之外的微不足道的錯誤導致了 bug。過了一段時間，重新使用這段代碼的時候，又出現了新的 bug， 但偏偏還不能怪別人，畢竟是自己寫的代碼，血壓上來了.jpg。程序説變量未定義那就真的是未定義，説變量類型不對那就是真的不對，總不能砸電腦吧。

有沒有什麼辦法可以減少和規避 bug 呢？本期的主題「單元測試」就是一種方法。一段代碼在運行時出現 bug，意味着 bug 可能出現在代碼任何地方。代碼越長，定位 bug 越困難，反過來説，代碼越短，定位 bug 越容易。如果儘量保證每一小段代碼都能正確執行其功能，那麼它們組裝起來也應該能正常工作。這裏的小段代碼通常指單個函數，它們組裝起來，就是整個程序。單元測試要做的事，就是儘量保證每個函數都能正確執行其功能。

Notebook 上手實踐

本期 Notebook 將從實際情形出發，從讀者熟悉的事物引出單元測試，介紹單元測試的含義和基本用法。我們並非試圖告訴讀者所有關於單元測試的細節，而是希望讀者從整體上理解做單元測試的意義和單元測試的本質。請放輕鬆，這並非艱深的話題，不需要額外的經驗，只要你寫過代碼，就完全可以將本期作為電子榨菜。如果你對單元測試感到好奇，不妨親自打開 Notebook 試一試，希望你能從中收穫新的知識。

歡迎大家來 Notebook 案例廣場，獲取更多有意思的實踐～

感興趣的同學也可以點擊原文查看.