軟件單元測試

開始編碼的時候沒有人告訴你什么是測試。很大的一個問題擺在我們面前，如何驗證自己編碼的正確性。當然，你可以把這些問題留給系統的使用過程之中，但那個時候發現真正的代碼中存在的問題，就變得非常困難，而這時代碼中一旦存在大量的耦合性，真正修正一個問題，就變得更為困難。于是，我們需要在更早的時候發現問題，同時我們需要把一個耦合的復雜問題轉化為多個簡單的內聚單元，由是單元測試隨之產生。

　　傳統的軟件工程中把單元測試放在編碼之后，而單元測試的執行人通常就是程序員本人，這個時候程序員依賴自己的預期對分解了的程序單元模塊（通常是一個函數或者方法），按照一定順序執行自己的期望測試，通過執行一個驅動模塊，調用程序中的樁?？?，得到一個預期結果，比較預期結果和期望結果，如果一致那么測試通過，否則通過代碼走讀或者逐行調試，發現隱藏在代碼中的問題，最終使預期結果和期望結果保持一致。

　　大型軟件開發和中小型軟件開發的差異，在軟件開發過程和軟件開發方法中國外的一些知名程序員開始對單元測試的理念進行改進。軟件工學本身就是一個自醒、改進的體系。隨著新興敏捷和xp理念的引入，Test driver development(TDD)已經成為一個單元測試的另一種理念。和傳統理念的差異是TDD把單元測試放在了代碼功能模塊之前，前置測試的引入，使我們將OO令人敬畏的理解變成面包和水，我們引入Mock Object ，而這正好是在我們尚未用代碼構建我們的系統之前。這樣的好處顯而易見，測試代碼獨立于開發的代碼單獨存在，每個測試代碼都有一個目的，在TDD的測試工具中Xunit獨樹一幟，尤其是經典的Junit，斷言的引入，使我們明白每個程序單元究竟要完成怎樣的目的。如果寫單元測試用例的人和寫被測單元的人是同一個，前置測試，使他在編碼以前就明白自己每塊程序的目標，而且所有的目標都建立相應的成功標準。開發的時候他就會更準確的實現這些目標，在完成開發代碼之后，執行那些獨立的單元測試，我們很容易看到結果，由于斷言的引入，假設每個斷言確實反映了每個函數的目標，發現斷言失敗之后，我們需要小心的檢查代碼，找出那些造成斷言失真的問題。這樣作的另外一個好處，就是促成了單元測試的自動化，而這正是我們不再想看那些令人眼花屏顯輸出時的最好解決方法。而假設單元測試的編寫者和編碼者不是同一個人，似乎我們又找到了一種良好的監督機制，最終的結果就是讓那個被監督的人完成應有的測試目標。

原文轉自：http://www.kjueaiud.com