在剛過去的一個月中，我完成了一個小軟件框架的設計與實現。期間由于并行開發的需要，在沒有對代碼完成單元測試的情形下我將之check in到了SVN的主干上，隨后的心情很是忐忑。因為我知道我一定會犯錯（事實也證明在單元測試完成之前就發現了兩個缺陷），害怕給他人帶來麻煩并影響自己的形象。
另外，由于對剛加入項目的單元測試環境完全不了解，所以在該框架的前期開發工作中我并沒有運用單元測試漸進地保證軟件質量。其結果可想而知，我花了不少時間去修復編碼過程中遺留下來的低級錯誤。需要指出的是，所在項目是一個大型嵌入式系統，項目編譯一次就得20分鐘左右，調試效率可以想象。與之不同的是，單元測試可以在Linux/Cygwin這樣的環境中完成，加上可以使用gdb進行調試，開發效率提高一個數量級應不是問題。
由于我深刻地體會到了單元測試對工作與生活質量的重要性，所以持“真正高質高效的軟件開發工程師，一定是那些深刻理解并切實實施單元測試的人”這一觀點。然而，就我過去幾年的工作見聞來看，發現身邊絕大多數的工程師并沒有真正用心去擁抱單元測試。出現這樣的狀況，我認為存在一定的原由，因此想借本文談談一些認識。
有相當一部分工程師是因為并不了解什么是單元測試而沒能嘗到單元測試的好處。一部分人認為，平時開發工作中的調試其實就是單元測試（參見《明析單元測試》），有的則因為沒有花時間學習單元測試而對之不了解。對于這些新手，我并不打算在本文對之“掃盲”，請下載ClearRTOS源碼（點擊下載）和本文的附件自行學習。 ClearRTOS 是我為《專業嵌入式軟件開發》一書所設計的、可在Cygwin和Linux環境中運行的“實時”操作系統，其中涵蓋有單元測試方面的內容，更具體的信息見文后。
另外的一部分人盡管實施過單元測試，但卻沒能從中受益，甚至得出“單元測試無用”的結論。這部分人的困惑是我最想在這里加以指出的。歸結起來，我認為實施過程中的“縫太大”是其中一大主因。
不少團隊將項目的產品代碼與單元測試代碼加以區別對待，這是產生“縫”的第一大根源。表現之一是，編譯產品代碼與編譯單元測試代碼采用完全不同的編譯環境，程序員在日常工作中需要不停地在兩個編譯環境中進行切換。這種方式很容易讓工程師感到麻煩，甚至因此遭到抵制或棄用。好的方式是，將單元測試代碼的編譯環境與產品代碼進行無縫整合。比如，在嵌入式系統項目中做到運行“make release”或“make debug”實現產品代碼編譯，運行“make unitest”完成單元測試代碼編譯（ClearRTOS項目就是這么做的）。做到編譯環境的無縫整合需要團隊中存在精通編譯環境構建語言（比如Makefile）的專家。很不幸的是，這方面的專家少得可憐，團隊對這方面知識的精進也因為沒有意識到其重要性而缺乏動力。
表現之二是，產品代碼與單元測試代碼區別維護。采用這種方式的團隊，很容易在工作中將單元測試擺到更低的位置，開發過程會先以產品代碼為主，然后（有時間時）再補上單元測試代碼。這種方式很容易降低實施單元測試的效果，且容易因為產品代碼與單元測試代碼的不同步而帶來更大的維護成本。實際上，實施單元測試的一大好處就是在對產品代碼進行變更時，通過及時實施單元測試保證軟件質量。及時維護單元測試代碼從短期和長期都具有很好的經濟性，而非象我們想象的那樣成本高昂。
產生“縫”的第二大根源，是因為工程師在單元測試過程中不能方便地獲得代碼覆蓋報告。以我的觀點，代碼覆蓋報告應在開發環境中運行象“make creport”這樣的命令而輕松獲得（ClearRTOS項目同樣實現了這一點）。我看到過一些項目，工程師為了獲得覆蓋報告，需要登錄到一個Web服務器上才能查看，而非在工程師的工作機器上隨手獲取。
產生“縫”的另一大根源與單元測試的“打樁”方法有關。被廣為采用的方法是通過使用象Cmockery這樣的單元測試框架以打樁的形式，將被測模塊獨立出來。這種方式盡管被廣泛采用，但我覺得所需付出的成本還是很高的。因為“樁的世界”與“產品代碼世界”存在很大的“縫隙”，維護期間需要不停地在兩個“世界”進行切換，更好的方式是將樁代碼融入到產品代碼中（細節我想通過另一篇文章給出）。
盡管我認為單元測試是一種有效的質量保障方法，但其有效性在工程界和學術界都存在一定的爭議。
關于ClearRTOS
ClearRTOS現在是一個開源項目，讀者可以通過SVN獲取將來的新版本。為了能在ClearRTOS項目中獲得HTML格式的代碼覆蓋報告，讀者需在Linux/Cygwin中安裝LCOV（鏈接）。
在ClearRTOS項目中獲取代碼覆蓋報告的步驟如下：
1）運行“tar xzvf ClearRTOS.tar.gz”解壓。
2）運行“cd ClearRTOS/build”進入編譯目錄。
3）運行“make unitest”編譯單元測試程序。
4）運行“make test”執行單元測試程序。
5）運行“make creport”獲取單元測試報告。報告可用IE、Chrome等瀏覽器打開ClearRTOS/build/coverage/index.html文件進行瀏覽。通過點擊網頁中的相關鏈接可以查看到每個源文件的代碼覆蓋情況。