近來特別關注單元測試的應用。大家可能會笑了，單元測試都N年前提出的了，您老怎么現在才來做呢。是的，單元測試幾乎人人都在提，但是真正做好的沒幾個。
我們幾個同事在討論這個的時候，發現這里面有很多因素。相信大家也在實踐過程中都遇到過。
單元測試測什么這是最經常被提到的問題。往往有三個答案：
針對代碼測試，往往也被稱為針對類進行測試。 針對模塊接口進行測試。這種模塊往往是沒有界面性質的。 針對業務功能進行測試。類似于模擬需求測試。在回答這個問題之前，我們都回顧一下，《測試驅動開發》中，強調的是Story的概念。Story就是一個應用場景。用程序的語言的來翻譯的話，就是將需求實例化。
但是KENT BECK顯然沒有將這個概念明確化。這樣難怪，業務模型，是基于不同層次來說的。如果你只是設計一個類，那么這個類本身也是有需求的。那么這個類的需求和整個軟件的需求是不是一致對待呢？
個人傾向于第三類的測試，一二為補充。
不過這里重點說一下業務功能的測試難點，那就是模態窗體的測試。這個難點的罪魁禍首是Windows的消息機制決定的。每一個模態窗體都有自己的消息循環（死循環）在處理消息，當從一個模態窗體切換到另一個模態窗體的時候，測試代碼就不能繼續下去。
針對這個問題，我的處理方式，就是“解鈴還須系鈴人”。通過Windows的消息循環就可以穿透這種切換的休克。當然了，處理方式還是比較復雜的。
單元測試代碼不能工作了這往往是單元測試不能繼續的借口。應該說，很多人還是熱衷于進行單元測試的�？墒悄阍诤笃谠儐枂卧獪y試的作用的時候，他們就會非常遺憾地告訴你，由于需求變更太頻繁，單元測試代碼已經不能工作了。
如果你有相似經驗，你會非常贊同這個原因。因為，畢竟單元測試側重的是軟件質量，可是我們往往直接面對的是軟件進度。沒有人會告訴你面對質量和進度，應該選擇什么。但是你知道，你只有選擇進度。
幾乎所有的程序員都能明白，前期的質量，會節省后期的進度。但是好像老板不知道。至少，很多程序員都相信這點。
不管怎么說，單元測試代碼真的就這么放棄了嗎？其實很簡單，在你的考核體系中，加上單元測試代碼失敗的懲罰。因為選擇一個技術，只是一個決策問題。而保障一個技術，那就是管理問題了。
不過，要注意的是，永遠忘記單元測試必須時刻進行運行。每一次代碼簽入的時候，必須運行一次。必須認識到，有了這個自動機制，才能保障你的單元測試持續工作下去。
單元測試需要設計非常多的人都認為，一個系統如果不針對單元測試進行設計，那么其可測試性就會降低，以至于不可以繼續下去。
我并不懷疑設計的必要性，但這個說法最讓我不得不懷疑另一個看上去毫不相干的觀點：嘗試和執行單元測試，需要的是勇氣和決心。
這點其實KENT BECK在XP開發方式的介紹中，就說明了這個問題。作為執行的主體，人的性格很可能影響最終執行結果。
小結軟件工程中有很多新的工具，但我們往往發現叫好不叫座，而原因往往也是使用中國的一句古話就是：具體問題具體分析。但是回過頭來分析一下，其實很多具體問題都是可以有辦法解決的。將這些總結貢獻出來，希望我們中國的軟件技術走得更快點。
文章來源于領測軟件測試網 http://www.kjueaiud.com/