這裏主要想討論一下單元測試，目前Unit Test越來越被主流開發平臺看好，先是Eclipse、NetBeans，現在又是VisualStudio 2005，甚至在Team System中還能施加強制Unit Test的Policy，將來的Weblogic Workshop 9可能也會進行相關集成，業界對此重視程度可見一斑。雖然Unit Test的好處不言而喻，但至今在中國，多數的項目開發仍然不會實施單元測試，即使有實施的，很多也是在外部Policy的壓制下被迫進行單元測試的編寫，以滿足那字面上的測試用例代碼覆蓋率，真正程序員主動給程序配上單元測試的項目少之又少。其中很重要的一個原因便是多數人認爲單元測試極大地浪費了他/她們的開發時間，降低工作效率。其實自從前段時間對XP的實踐之後，我能清晰地感覺到Unit Test帶來的不僅是軟件質量的提升，更是開發效率的提高，這是什麼道理呢？看完本文便有答案了。
一個不能忽視的問題是，目前很多軟件開發過程中的測試仍然只是隨便搞點數據，跑過算數，所謂測試用例的個數毛估估的也是個別現象，我認爲這不能算是成功的測試，而且也會爲日後項目的進展埋下隱患。說老實話，單元測試並不容易，當然如果我程序的每個類實現的都是加法減法這樣的操作，那單元測試或許是相當好寫的，可現實世界紛繁複雜的業務邏輯、大量的數據庫操作佔據了絕對主流，如何進行單元測試呢？
單元測試也有一些原則，首先便是測試先行！無論要實現什麼功能，XP的主張：先寫測試。在書寫測試的過程中，程序員學習並深入瞭解需要實現的業務邏輯，發現疑問並尋求解答。這是Test Driven Development(TDD)的基本實踐，可以避免程序員盲目書寫程序代碼可能蘊藏的隱患，在沒有完全瞭解或自以爲完全瞭解業務邏輯的情況下寫出來的代碼很有可能會在將來的某一天被重構或修正掉，與其到那個時候去費工作量，還不如靜下心來考慮考慮將要做的程序到底是怎樣運作的，有哪些意外情況可能會發生。
其次是無依賴原則，即任何一個單元測試的運行及其結果都不依賴於外部環境，這些環境可能包括操作系統環境變量的配置、數據庫中的數據、運行的時間等等。無論何時運行，只要代碼不變，結果都應該是一致的。其中接觸最多的可能就屬數據庫了，在單元測試中，開始對代碼進行測試之前，首先要準備好測試可能需要的數據，通過把準備數據的代碼寫入單元測試中，可以達到一勞永逸的效果，一次編寫，多次執行，也爲自動測試提供了可能。當然設計這些數據往往很費腦筋，要能做出足夠量的能測出所有相關業務邏輯的數據並不是很輕鬆的工作，但也正是在這樣的設計過程中，充分考驗程序員對需求的認知程度，最大程度避免程序的漏洞和死角。
然後是無蹤跡原則，即測試運行前後系統狀態保持一致，數據庫的數據也不因測試而發生增減，所有測試生成的數據一律刪除。這就如同是MGS中的Snake不能留下任何潛入的足跡一樣，XP主張單元測試也要不留痕跡，這也是多次自動運行結果一致的重要保障。所以在編寫單元測試時，清場的代碼千萬不可忽視，尤其是那些由正常的業務邏輯代碼生成的數據，一定要想辦法抓住特徵，予以刪除。
最後是進化原則，這也是XP的簡單教條在測試方面的體現。無論何時都不應期望在一開始就寫出面面俱到毫無破綻的測試用例。隨着經驗的增長，首次測試案例的質量會愈加提升，但在一開始就進行過度測試是不可取的實踐。在集成測試中必然會暴露單元測試未能成功捕捉的bug，此時對原先的單元測試進行修改，並通過衰退測試（即用新的測試代碼捕捉原有程序的漏洞）驗證新的單元測試是有效的。單元測試也和業務代碼一樣始終處於不斷修正、充構、進化的道路上。
說到這裏，再來總結一下爲什麼單元測試提高了開發效率，首先是其一次編寫多次自動執行的特徵使得準備完善測試數據的工作量得到大大減輕，其次在發生代碼重構時，把單元測試全部運行一遍便足以保證重構沒有給系統帶來破壞性的打擊，這種情況下若是沒有單元測試，那某些牽一髮而動全身的重構或代碼修改可能導致的後果就沒人能說清楚了，組織人力對所有可能受影響的模塊進行人工測試又是另一個龐大的工作量。看似單元測試使程序員多寫了很多代碼，事實上在很大程度上降低了可能的工作強度，而且使程序員也更爲自信，做到面對任何代碼修正都心中有底。
當然，單元測試只是測試的一個方面，之後還有界面測試、壓力測試等等，我並不想以偏概全，因爲自己也曾經吃過光重視單元測試忽視其它測試的苦頭，我想說明的是單元測試在目前國內開發實踐中的運用還是相當欠缺，而它能解決的問題卻是最多的，希望有更多程序員出於自身的需要、發自內心地投入到單元測試的隊伍中來。