單元測試不僅僅是給老板帶來了高質(zhì)量的軟件，還會讓你（程序員）體驗(yàn)一個愉快的過程，信不？
即時反饋
人產(chǎn)生一個行為（做了一個動作、一件事），總是期望知道這個行為是否產(chǎn)生了預(yù)期的效果、達(dá)到了預(yù)期目的，以便調(diào)整行為（若未達(dá)到預(yù)期）或進(jìn)行下一步（已達(dá)到預(yù)期）。
如果能馬上知道，人的心理就比較輕松；如果持續(xù)這種 行為--反饋 的過程，人的心理就會有一些快感，從而讓人喜歡上這個過程。這就是即時反饋的魔力
相反，如果一個行為產(chǎn)生之后，需要較長時間才能知道結(jié)果，那這個等待的過程中人的心理就有疑慮、有負(fù)擔(dān)——懸而未決的事總是會讓人產(chǎn)生這樣的負(fù)擔(dān)。如果持續(xù)面對這樣的 行為--等待--反饋，就會對這個過程產(chǎn)生厭倦，進(jìn)而抗拒。
列舉一些日常生活和編程中可以用這個機(jī)制來解釋的現(xiàn)象：
- 一個App的按鈕響應(yīng)很迅速，用戶體驗(yàn)就好
- 網(wǎng)頁加載時，loading時間太長，人就很煩躁
- 寫代碼時，一般是寫幾句之后就會編譯一下，看有沒有語法錯誤（編譯型語言；或重新加載一下，看是否是預(yù)期的樣子（腳本語言）
- 調(diào)試時不能設(shè)斷點(diǎn)、不能單步調(diào)試，是不是很痛苦？
想象一下，寫代碼時讓你“盲寫”——沒有調(diào)試途徑，直到你完成全部功能，才給你調(diào)試的機(jī)會。這樣的開發(fā)模式是不是會讓人瘋掉？再想一下是什么東西讓你瘋掉的？是不是你根本不知道你寫的每一行代碼有沒有語法錯誤、邏輯對不對，這種感覺讓你抓狂。好比是黑燈瞎火走路，你根本不知道下一步會踩到哪里。這是沒有反饋的極端情況。
單元測試
單元測試就是為程序員創(chuàng)造即時反饋的一個利器。當(dāng)然，調(diào)試器也是因?yàn)槟?strong>即時反饋而成為開發(fā)必不可少的工具?？梢哉f，單元測試又向前推進(jìn)了一步，而且把你需要多次重復(fù)的動作給自動化了——又是一個額外的收益。
想象一下，你寫每一個方法、每一個類，你都能即刻、確切知道是否達(dá)到了預(yù)期目的，那樣你的心是多么輕松愉快，一切都在你的掌握中。這樣持續(xù)下去，你寫的軟件絕不可能是“失控”的。
阻礙
- 寫單元測試代碼也需要時間，而且功能代碼改了，測試代碼也需要同步修改，需要時間。這是額外的開銷。
- 要做到代碼覆蓋率很高（比如1:1），很不容易。
