單元測試之關鍵問題解答

近來特別關注單元測試的應用。大家可能會笑了，單元測試都n年前提出的了，您老怎麼現在才來做呢。是的，單元測試幾乎人人都在提，但是真正做好的沒幾個。

我們幾個同事在討論這個的時候，發現這裡面有很多因素。相信大家也在實踐過程中都遇到過。

這是最經常被提到的問題。往往有三個答案：

針對**測試，往往也被稱為針對類進行測試。

針對模組介面進行測試。這種模組往往是沒有介面性質的。

針對業務功能進行測試。類似於模擬需求測試。

在回答這個問題之前，我們都回顧一下，《測試驅動開發》中，強調的是story的概念。story就是乙個應用場景。用程式的語言的來翻譯的話，就是將需求例項化。

但是kent beck顯然沒有將這個概念明確化。這樣難怪，業務模型，是基於不同層次來說的。如果你只是設計乙個類，那麼這個類本身也是有需求的。那麼這個類的需求和整個軟體的需求是不是一致對待呢？

個人傾向於第三類的測試，一二為補充。

不過這裡重點說一下業務功能的測試難點，那就是模態窗體的測試。這個難點的罪魁禍首是windows的訊息機制決定的。每乙個模態窗體都有自己的訊息迴圈（死迴圈）在處理訊息，當從乙個模態窗體切換到另乙個模態窗體的時候，測試**就不能繼續下去。

針對這個問題，我的處理方式，就是「解鈴還須繫鈴人」。通過windows的訊息迴圈就可以穿透這種切換的休克。當然了，處理方式還是比較複雜的。

這往往是單元測試不能繼續的藉口。應該說，很多人還是熱衷於進行單元測試的。可是你在後期詢問單元測試的作用的時候，他們就會非常遺憾地告訴你，由於需求變更太頻繁，單元測試**已經不能工作了。

幾乎所有的程式設計師都能明白，前期的質量，會節省後期的進度。但是好像老闆不知道。至少，很多程式設計師都相信這點。

不管怎麼說，單元測試**真的就這麼放棄了嗎？其實很簡單，在你的考核體系中，加上單元測試**失敗的懲罰。因為選擇乙個技術，只是乙個決策問題。而保障乙個技術，那就是管理問題了。

不過，要注意的是，永遠忘記單元測試必須時刻進行執行。每一次**簽入的時候，必須執行一次。必須認識到，有了這個自動機制，才能保障你的單元測試持續工作下去。

非常多的人都認為，乙個系統如果不針對單元測試進行設計，那麼其可測試性就會降低，以至於不可以繼續下去。

我並不懷疑設計的必要性，但這個說法最讓我不得不懷疑另乙個看上去毫不相干的觀點：嘗試和執行單元測試，需要的是勇氣和決心。

這點其實kent beck在xp開發方式的介紹中，就說明了這個問題。作為執行的主體，人的性格很可能影響最終執行結果。

軟體工程中有很多新的工具，但我們往往發現叫好不叫座，而原因往往也是使用中國的一句古話就是：具體問題具體分析。但是回過頭來分析一下，其實很多具體問題都是可以有辦法解決的。將這些總結貢獻出來，希望我們中國的軟體技術走得更快點。