序
現在很多公司都在抓質量，質量！質量！質量！為什么都在抓質量，在IT行業多元化復雜化的今天，也就意味着競爭會異常的激烈，那么作為互聯網軟件公司，怎么提升我們的競爭力？我們不是某些國企，不需要某些套路，我們的企業是否能生存，取決於我們的用戶，抓住我們的用戶，我們就能生存，怎么抓住我們的用戶？那必須要獲得用戶的信任，讓他們能放心的投資在我們身上，購買我們的產品。
抓住我們的用戶，那么我們就需要提高我們的產品質量，這也是取得用戶信任的關鍵步驟，那么我們是做軟件的，就必須要提高我們的軟件質量。針對軟件質量可以從很多方面去提升，開發，測試，運維等等。開發里面又要分靜態檢查，白盒測試；測試里面又要分功能測試，性能測試等等，每個環節都有很多提高我們質量的方法，今天呢我只針對開發來講怎么提高我們的代碼質量，而且只針對白盒測試，也就是單元測試。
我曾經待過的公司，幾乎上到公司CTO，下到開發，幾乎人人鼓吹白盒測試有多好，對質量的殺傷力有多大，可是，能真正做起來單元測試的公司少之又少，小公司基本不願意投入做單元測試的人力成本，大公司呢，說起來容易，個個開發幾乎都是自己寫完代碼自己測試兩次了事~那么我們到底有沒有必要來做單元測試呢？我來說說我的觀點，分別從時間和工作量來分析。
時間
即使你沒有多少開發經驗，你也應該能夠想象，單元測試最大的問題，就是它需要花時間花精力去寫，那么這個花費是否值得呢？這還是由你架構的目標決定的，或者你的需求決定的。如果系統是一次成型交付使用，此后幾乎不會更改的，那么一次性的手工測試就夠了；但如果你的系統是會被“千錘百煉”的不斷折騰修改的，那么這個測試就是很有必要的。最簡單的考慮：每一次更改，我都要手工測試一次；那還不會如我多花點時間，弄個“自動化”的東西出來。單元測試，其實就可以理解為一種自動化的測試工具。
但是“自動化”的理由還遠遠不夠。因為你馬上想到的，每一次需求變更代碼調整，測試代碼也得相應的改呀？沒有測試代碼，我就只需要改開發代碼；現在有了單元測試，我還得再改測試代碼。本來我只維護一套代碼，現在我憑空增加了一套代碼也需要維護，這不是增加了維護成本，不是和你“可維護性”的架構目標背道而馳了么？是一套代碼好維護呢，還是兩套代碼更好維護？
這是一個非常好的問題，適用於很多情景（比如分層架構，你說分層解耦，實際上還不是一改就得從UI層改到數據庫，每一層都得改？）。我能給出的回答大概有：
一、無論有無單元測試，開發代碼進行修改之后，是不是都要進行測試？沒有單元測試，並不代表你的代碼就不需要測試了，只不過是你手工的去測試了一遍而已。切記：程序員的工作並不只是把代碼寫出來而已！
二、進行手工測試，和更改單元測試，兩者的耗費比，會根據測試重用的次數而變化。一次手工測試可能需要5分鍾跑完，更改單元測試代碼可能需要20分鍾，但如果這測試會跑100遍，單元測試完勝手工測試。你說，哪里喲？什么功能會改100遍？我沒說你的功能會改100遍，我說的是測試會跑100遍。有區別么？
工作量
所以其實當對象間的關系變得越來越錯綜復雜，像一張密密麻麻的網一樣之后，一個局部的改動就很有可能會觸發極其復雜的連鎖反應。所以為了保險起見，所有可能相關的組件都應該進行測試（所謂的“回歸測試”）。這時候如果只有純粹的手工測試，會面臨兩個問題：
- 難以確定測試的邊界（那些部分可能會被影響），憑空想？手動代碼走讀？
- 極大的測試耗費。而且這種耗費是相當的無聊繁瑣傷人心的——沒人願意做這種事。
測試只能告訴你出了bug，不能告訴你根源啊。沒有單元測試，單步調試需要花更多的時間。這是系統本身的復雜性，或者代碼組織的不合理造成的，不能歸咎於單元測試。不還是有這么多開源代碼都有詳盡的單元測試么？他們是怎么做到的呢？在單元測試上的付出，最終一定會獲得超值回報！想想沒有單元測試的公司，那超級龐大的測試團隊，或者四處冒煙的系統，你願意走這么一條路么？
這樣一種說法：可測試的代碼不一定是好代碼，但壞代碼幾乎是不可能被測試的。深度耦合的代碼，寫他們的單元測試，難於上青天；但反過來，我們可以以可測試為標准，不斷的完善重構開發代碼，只要這樣堅持下來，最終代碼的質量怎么都不會差到哪里去。
總結：所以，個人觀點，對於某些關鍵功能和通用底層庫，必須要做單元測試，如果真的要把產品所有的代碼都做單元測試，其實是沒有必要的，也不必要花這么多的財力人力。當然，通過做單元測試，不僅能提升公司產品的競爭力和穩定性，也可以提升開發人員的開發能力。