今天嘗到了單元測試的甜頭，以前對單元測試有偏見，覺得它是代碼編寫工作中的負擔，現在看來，我應該呈清一下。
首先，單元測試不是業務邏輯測試，它的測試對象應該是（但不限於）一個很簡單的功能。說道簡單功能，我想我有必要再深入一下我這裡指的簡單功能到底是什麼。
我們可以分析一下我們寫過的代碼，不難發現我們的代碼可以大致分為（但不限於）兩種：一種為業務邏輯代碼；一種為和業務邏輯完全沒有關系的功能代碼。例如：計算打折的代碼屬於業務邏輯代碼，但是如果在打折過程中，有將打折數據從datarow轉換為實體對象的代碼，這部分代碼實際上實現的是一個數據轉換功能，和業務邏輯沒有任何關系，在系統中處於最底層，在開發周期中處於最前端，在邏輯上又最單純，這部分代碼就是我所指的功能代碼。有的時候，我覺得程序執行的過程實際上就是數據轉換的過程，或是將數據的物理形態由一種形式轉換為另外一種形式；或是將數據的邏輯形態由一種形式轉換為另外一種形式。而前者，大多是我所指的簡單功能，這才是單元測試的對象。
周五的時候，我和以前一個做醫院系統的朋友討論了一下工作中遇到的問題，在談話中，我感覺到後來也認為確實是這樣：那些簡單功能的代碼一般處於系統的底層。這是一個事實，在系統最後進行組裝測試的時候，由於底層產生的問題，會由於系統當前的復雜度而被放大（其程度是不可估量的，就要看編寫代碼的那個人的經驗了，甚至要看運氣了。說實話，寫到這裡，我覺得“運氣”二字很恰當，確實在實際的工作中，在最後運行代碼的時候，我也帶有這樣的心理：希望有好的運氣，不要有難纏的bug出現。）。
正如我們頭推薦的那本書裡說的那樣，單元測試的目的是為了保證每一個已有的功能是正確的。當每一個簡單的功能都是正確的，那麼將它們組合起來，組合的結果會是錯誤的嗎？（呵呵，這是一個很有意思的邏輯問題）
而以前我認為，單元測試就是要去測試那些很復雜的邏輯模塊的接口，雖然至今我還不敢斷定我的這種認識是否是正確的，但是我體會過，要用單元測試來測試這樣的模塊的結果是你要付出很大的代價，最終讓你對單元測試望而卻步。
回到對代碼的分類，實際上當我想到將代碼分為業務邏輯代碼和簡單功能代碼的時候，我就認定，簡單功能代碼是單元測試的對象。自己也就是在這樣的實踐中，讓我從新認識了單元測試。
其實單元測試的效用還不僅如此，如果你的系統設計中存在軟肋，可以針對它編寫專門的單元測試（這也許是用工程管理來平衡工程設計的一個例子）
發現單元測試的過程，實際上也是發現代碼價值，認清代碼本質的過程，討論單元測試，應該更（但不限於）加關注單元測試的對象，至少目前我是這樣認為的。
希望各位 高手多多指教。
