關注我的微信公眾號：小爭哥，獲取更多、更新的技術、非技術分享。
作者：前Google工程師，5萬人訂閱《資料結構和演算法之美》專欄作者。
希望通過我加速你的技術、職場進步。
在上週發的一篇文章中，我講到了提高程式碼質量的幾個方法。有讀者對其中的單元測試比較感興趣，今天，我們就聊下：有沒有必要寫單元測試？有了測試團隊，再寫單元測試，是否是浪費開發時間呢？
1. 單元測試到底用來測試什麼？
以免有讀者對單元測試不瞭解，在討論這個話題之前，我先簡單科普一下，什麼是單元測試？
單元測試，顧名思義，它測試的是一個小”單元”，這個”單元”一般是類或方法，而不是模組或者系統。
單元測試一般都是由開發工程師來完成的，是程式碼層面的測試，用於測試“自己”編寫的程式碼的正確性。
單元測試並不等於測試驅動開發。測試驅動開發是一個理想很豐滿，現實不可行的開發思想。而單元測試效果等同於測試驅動開發，但更容易落地執行。
單元測試不依賴於任何不可控的元件，如果程式碼中依賴了其他這些不可控的元件，比如複雜外部系統，複雜模組或類，則需要通過mock的方式，將這些不可控的部分變成可控。
實際上，寫單元測試本身不是一件需要高深技術才能完成的事情，更多的是考驗工程師思考的縝密程度，是否能夠設計出完備地覆蓋各種正常、異常場景的測試用例，來保證程式碼在任何預期或非預期的情況下都能正確執行。
2. 寫單元測試帶來的好處有哪些？
從我個人經驗來說，當我們寫程式的時候，一般都會側重正常情況下程式的執行是否符合預期，往往會對異常情況下程式的執行情況，考慮不夠全面。
在你寫完一個功能程式碼之後，怎麼保證你的程式碼執行正確？在各種異常（資料異常、輸入異常、呼叫異常等）情況下，程式執行結果都符合你預先設計的預期，返回合適的報錯呢？
這個時候，單元測試就派上了用場。從我個人寫單元測試的經驗來看，在寫單元測試的時候，幾乎每次都會發現很多考慮不全面的地方，都會發現很多”bug“。設計完備的單元測試用例，非常有助於掃清程式碼中的各種低階的bug。所以，我一直覺得，提高程式碼質量，最有效的手段，就是寫好單元測試。Google中有很多專案是完全沒有測試團隊參與的。程式碼的正確性完全靠開發團隊來保障，線上bug反倒是非常少。
而且，寫單元測試的過程本身就是一個自我code review的過程。在這個過程中，你可以發現一些設計上的問題，比如程式碼設計的不可測試，程式碼的可讀性不好等等。
寫單元測試還能增強你對程式碼的信心。等你寫好完備的單元測試，並且程式碼通過所有的測試用例的時候，你對自己寫的程式碼也會信心大增。這種一切盡在掌握中的感覺是很好的：）如果你好好寫過單元測試，那在這一點上，應該能跟我有所共鳴吧。
除此之外，單元測試還對重構程式碼也有很大幫助。當你發現某個類或者函式實現的不好，你想要重構一下，但又怕考慮不全面，改了之後會出錯，出力不討好，這個時候該怎麼辦呢？
如果有單元測試情況就不一樣了。程式碼重構完之後，你跑一下原來的單元測試。如果單元測試都通過，那基本上可以保證，你的重構沒有破壞正確性。不過，這個的前提是，之前寫的單元測試質量很好，覆蓋率很高。
3. 為啥很少有公司會寫單元測試？
據我瞭解，國內的網際網路公司，包括BAT在內，很少有認真寫單元測試的哈，特別是一些開發業務系統的專案組。我個人覺得，這個跟整個公司的技術文化、研發模式都有關係。
很多公司的技術文化，從上到下都沒有“程式碼質量”的意識。寫好程式碼只要能編譯通過，並且正常情況下執行符合預期，就直接提交，然後丟給測試團隊，狠命的測。測試團隊測出問題後，就反饋給開發團隊再修改。測不出的問題就留線上上出了問題再解決。
而且，我們很多公司都是996、995，業務驅動，進度催的緊。研發工程師根本就沒有時間、精力，來去寫單元測試了。因為，一般情況下，單元測試的程式碼量往往大於被測程式碼量，大約會是1-2倍的樣子。
在這樣的研發模式以及技術文化下，團隊往往覺得單元測試沒有必要，浪費時間。但是，如果我們開發團隊，把單元測試寫好，做好code review，重視起程式碼質量來，其實是對專案的一種長期投資。
有句話說的很好：“慢即是是快”。雖然寫單元測試、code review可能暫時會影響當下的研發進度，但是，從長遠來看，程式碼質量很高的專案，整體的研發效率會高很多。
最後
今天，我主要跟你科普一下單元測試，說說單元測試有啥好處。你也可以留言跟我說下，關於單元測試，你還希望聽聽啥內容？或者說說你對單元測試的看法，你的專案中有沒有寫單元測試？你覺得是否值得花時間去寫呢？