寫到這里，使得我回想起當年做網絡系統。當時的局域網絡都是采用環狀網絡，還沒有現在的交換機來組星形網絡。環狀網絡的傳輸網絡采用同軸細纜線，網絡中的所有節點都在一條主干線上，網絡的兩端都會加上一個電阻來形成一個環(如下圖)。
環狀網絡的最大的缺點就是當任意一個節點有固障時，整個網絡都不能連通。維護這種網絡是非常麻煩的。通常采用得比較多的方法就是“切香腸”法。把最后一個電阻取下來，接到第二臺電腦的網絡節點的末端，檢查兩條線是否能連通。連通后再把電阻取下來到第三臺電腦的網絡節點的末端，連上第三臺電腦。這樣來依次檢查整個網絡的線路。
后來就發展了星形網絡，也是現在局域網普遍采用的。有一臺交換機，每一臺電腦連接到交換機，任意一個節點網絡故障不會影響到其它節點，檢查起來就非常方便了。沒有單元測試的代碼就像是環狀網絡，而有測試的代碼就像星形網絡。
其次，有可能我們第一次編寫的代碼是沒有問題的，但是到后來需求改變而修改了其中某些類的代碼，把它發布到了應用服務器去測試，所要修改的內容已經測試通過了。但是因為某些類的代碼的修改導致了其它類不能正常的工作。這種bug往往隱藏得非常深，因為只要不觸動它，它就不會出現�？赡軙绦虬l布到生產環境之后才會被業務人員發現。如果每個類都有測試代碼，我們在打包之前運行所有測試代碼，就可以很容易的發現因為代碼修改帶來的連帶性錯誤。
最后，在離bug產生越近，修正bug就越容易;在bug產生越遠，修正bug的代價就越昂貴。假設我們去集成一個星期(甚至更長時間)前編寫的代碼，當發現問題時，我們已經忘掉了很多重要的實現細節,所以修改變得困難重重。
編寫單元測試，并不會加重程序員的負擔，反而提高了程序員對程序的信心，大大的減少了重復打包、發布、糾錯誤的時間。這些花費的時間遠遠要比編寫單元測試花費的時候多幾個數量級。編寫單元測試，可以讓你更容易和更放心地去修改代碼，增加功能從而加快了項目的開發進度。
為什么我們總是要主觀的去認為編寫單元測試會延緩項目進度呢?與其痛苦的掙扎，還不如去嘗試一下好的實踐。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
