什么是單元測試？
如果你聽過“測試驅(qū)動開發(fā)”（TDD:test-Driven Development），單元測試就不陌生了。
單元測試簡單來說就是對某個函數(shù)或者API進行正確性驗證。
比如對于函數(shù)abs(),我們可以編寫以下幾個測試用例：
- 輸入正數(shù)，期待返回值與輸入相同。
- 輸入負(fù)數(shù)，期待返回值與輸入相反。
- 輸入0，期待返回0。
- 輸入非數(shù)值類型，期待拋出typeError。
把上面的測試用例放到一個測試模塊里，就是一個完整的單元測試。
如果單元測試通過，說明我們測試的這個函數(shù)能夠正常工作，如果單元測試不通過，要么函數(shù)有bug，要么測試條件輸入不正確，需要修復(fù)使單元測試能夠通過。
單元測試的意義
單元測試通過后有什么意義嗎？
如果我們對abs()函數(shù)代碼進行了修改，只需要再跑一次單元測試。如果通過，說明我們的修改不會對abs()函數(shù)原有的行為造成影響，如果測試不通過，說明我們的測試與原有行為不一致，要么修改代碼，要么修改測試用例。
這種以測試為驅(qū)動的開發(fā)模式最大的好處就是確保了一個程序模式的行為符合我們設(shè)計的測試用例，在后期修改時，能夠極大程度地保證該模塊行為任然是正確的。
當(dāng)一個項目由多個人維護的時候，假如A寫了一個頁面，B去維護A的頁面加了一些邏輯，C去維護該頁面再添加一些邏輯，當(dāng)A再去維護這個頁面的時候，可能已經(jīng)不認(rèn)識他曾經(jīng)寫的代碼了，函數(shù)也不是原來的語義了，大部分的變量都不知道是干什么用的。那么A需要捋清楚B、C的邏輯，在B、C的基礎(chǔ)上再小心翼翼的編寫新的需求，生怕哪一步寫錯，導(dǎo)致線上的代碼出錯。長此以往下去，代碼變得越來越難維護，越來越少的人能看懂頁面內(nèi)的邏輯，糊墻式代碼將頁面堵得水泄不通！當(dāng)然這是最壞的想法。
所以依賴我們自覺去維護代碼，首先對我們個人能力有很高的要求，其次對我們的精力也很浪費。我們要時刻注意自己的代碼是否會影響到別人的代碼。從長遠(yuǎn)考慮，單元測試是一個大型項目的必然選擇。
