題外篇：單元測試難於長期堅持的原因與解決**
我以前主要關注如何做得了、做得快、做得好，幾乎沒有單獨考慮長期堅持的問題，原因大概是：對我自己來說，這不是問題，我已經做了十年的單元測試，這十年，我寫**時基本上都是一邊寫一邊測試。那麼，是什麼原因讓我長期進行單元測試呢？
這十年分為兩個階段，後六年專門研究單元測試技術與工具，前四年做一些外包專案。如果說因為單元測試已經成為我的專業，所以自己當然要做，那麼，這也不能解釋前四年之所以能堅持的原因。正是因為前四年的單元測試經歷，才使我後來專注於單元測試領域。
回首十年的單元測試歷程，我發現從來就沒有刻意去堅持。我不是乙個理性而有毅力的人，比較喜歡率性而為，能夠十年不間斷去做同一件事情，應該是因為，這其中有什麼東西吸引了我，讓我自然而然地想做而不是強迫自己去做。
一件事情，如果需要理性的力量，去勉強堅持，時間長了，熱情會減退，惰性漸占上風，慢慢的可能就放棄了，例如健康的飲食習慣。有些事情，雖然從理性方面看未必好，但卻容易使人沉溺其中不能自拔，例如玩網路遊戲。為什麼會這樣呢？後者具有眼前的和感性的吸引力，形成了「**」，自然讓人喜歡做，長期做。眼前的感性的吸引力，往往能輕易打敗後期的和理性的好處。
我想，正是因為單元測試的某些「眼前的和感性的吸引力」，形成了「**」，使我樂於去做，而不是勉強去做。那麼，是什麼產生了「**」呢？為什麼單元測試沒有形成普遍的「**」呢？我做的單元測試和一般的單元測試有什麼不同嗎？
回想起來，不同確實是有的，從一開始，我使用的工具都是自己參與開發的。當時由於找不到滿意的工具，所以自行開發，功能都是自己最需要的。
這個工具的第乙個版本，主要功能是生成測試**，修改一下就形成用例了。
第二個版本增加了自動生成用例的功能，使用之後很失望，因為工具不可能自動了解**功能，自動生成的用例幾乎沒有什麼用，在生成的一堆用例中去選擇和修改，還不如直接寫用例呢。
第三個版本增加了描述程式行為的功能，就是將被測程式在某些輸入下，執行了哪些**，產生了什麼輸出顯示出來，也就是程式行為是可視的。這個功能太好用了，寫幾行**就可以看看程式做了什麼，程式設計的效率提高了，而工作強度卻降低了，後來，我們把這種開發模式稱為「可視程式設計」，「可視」，是指程式行為可視。
我所用的工具和一般測試工具最大就不同就在於支援可視程式設計，我所做的單元測試，與一般的單元測試最大的不同也在於可視程式設計。一般的單元測試，關注的是測試是否通過，而我寫幾行**，執行測試後，首先看的是產生了哪些輸出資料，除了一般的引數、成員變數、全域性變數外，還包括中間結果，中間結果就是重要的變數或表示式在函式內部某個指定位置的值。如果輸出資料跟我預想的不一樣，再看看執行了哪些**，這樣就很容易找出錯誤，改正後再繼續寫。等**寫完了，最後再看看哪些測試沒有通過，並對比輸入輸出與對應的已執行**，找出錯誤原因，很少用除錯，我使用偵錯程式的能力已經嚴重退化了。
現在想來，「**」我樂於長期做單元測試的「眼前的和感性的吸引力」就在於可視程式設計。比如說正在寫乙個比較複雜的函式，如果程式行為不可視，那麼，我就要時刻想象已經寫的**會做什麼，思路對不對也心裡沒底，當然難多了也累多了，而且除錯最煩人，記得還沒有做單元測試的時候，有時為了找乙個小bug，三更半夜還在翻江倒海，好像什麼都沒錯，就是結果不對，恨不得把電腦砸了。如果一邊寫**，可以一邊察看程式做了什麼，感覺相當的爽，這就是「眼前的和感性的吸引力」。至於單元測試的其他好處，比較理性化，我一般不會想著這些好處的，反正只要做了單元測試，這些好處就跑不了。
可視程式設計強調是開發，而不是測試，不需要改變程式設計習慣，也不會造成思維被干擾，程式設計師是很怕被干擾的。如果工具比較自動化，可以生成測試**什麼的，那麼可視程式設計也不需要什麼額外的工作，我們在寫**時，一定需要想清楚**的功能點，功能點一般就是會有哪些輸入，各自會產生什麼輸出，列出來就是測試用例了，這不用花多少時間，而且還可以讓自己對程式要實現的功能有更清晰的理解。
只要做了單元測試，那麼，程式在什麼輸入下會執行哪些**產生什麼輸出，這些資料就一定會存在，問題是有沒有把它們利用起來。我覺得，多數單元測試理論和工具都忽略了這個寶貴的資源，是很可惜的。
如果感覺可視程式設計確實不錯，也有望解決難於堅持的問題，那問題就有望解決，因為，不管您用的是什麼工具，只要做了單元測試，那麼，能夠讓程式行為可視的資料是一定存在的，想辦法把它們捕獲就是了。捕獲的一般方式是插裝，就是在被測**中插入一些**，用來輸出資料以及監視**的執行狀況。
當然，要讓單元測試真正順利，還要消除會使測試「卡住」的主要阻礙，解決可測性問題，還要有好的測試效果，以及盡可能高效率，後面的篇章，會討論這些問題。
C C 單元測試理論精要（二）
1.2 單元測試的目標和方法 單元測試的目標是什麼呢？就是完整檢測 單元的功能邏輯。找出 單元本身的所有功能邏輯錯誤，具體來說，就是檢測對資料的各種分類是否考慮全面，處理是否正確。單元測試並不是用來代替系統測試 效能測試的，它的目標相當明確，就是檢測 單元本身的功能邏輯錯誤。如果時間緊張，應該優先測...
C C 單元測試理論精要（六）
2.1 可測性問題詳解 2 接下來我們討論重點問題 覆蓋輸入。乙個函式，輸入會有哪些呢？輸入包括兩方面 外部輸入，內部輸入。外部輸入容易理解，就是函式外部可以設定的輸入，包括引數，全域性變數，成員變數。關鍵是內部輸入。因為很少有文獻討論內部輸入，對很多人來說，內部輸入可能是乙個陌生的詞，我們首先來看...
單元測試 理論篇
測試是軟體開發的重要環節之一。按照軟體開發的過程測試可分為 單元測試 整合測試 系統測試 域測試 field test 等。我們這裡將討論面向程式設計師的單元測試。本文首先介紹單元測試的定義，為什麼要使用單元測試？單元測試能給我們帶來的好處。之後我們將介紹單 元測試的範疇，最後將討論很多朋友不寫單元...