對復雜的單元測試使用模擬對象

　　對復雜的單元測試使用模擬對象 軟件測試

　　如今，程序員比以往更多地認識到他們有責任創建編寫較好的單元測試。無論一個開發人員是在進行測試驅動的開發(TDD)還是在編寫代碼后創造單元測試，有一點是十分明顯的，那就是單元測試有助于產出高質量、無缺陷的代碼。

　　即便開發人員知道測試的益處，我們也會發現程序員們不愿意測試他們的代碼。他們會列出各種理由，如時間不夠、沒有有效的工具以及在編寫帶有許多有依賴關系的對象的測試方面有問題。

　　本期的文章中，我想將重點放在單元測試上，并看看如何解決這些問題。特別地，我想提供一些技巧來說明編寫帶有模擬對象的單元測試是多么容易。

　　對于單元測試的常見異議

　　在深入探討模擬對象之前，讓我們先來看一下以下兩點異議。

　　花費時間太長

　　我們很早就認識到這樣一個原則“做事情需要花費時間”，特別當這些事情值得去做。很少的開發人員會懷疑整體測試的價值，因此我們需要考慮如何定義“太長”這個詞的含義。

　　開發人員們缺乏耐心，他們想要的是結果。他們喜歡寫代碼、運行代碼然后看結果。從這一點來說，單元測試對他們有幫助。單元測試滿足開發人員們的及時需求，但是許多程序開發人員認為編寫測試占據了他們編寫應用程序代碼的時間，而他們的工作是按照后者計算報酬的。當然如果您僅僅按照程序開發人員在一個特定時間創建的應用程序代碼的行數(或者一些其他方法)來計算的話，這一點是正確的。但是我們必須考慮每行代碼所承載的全部時間。如果每當代碼編譯完成并運行通過我們就停止計算的話，我們可能會忽略掉創建軟件最重要的部分—消除缺陷。在軟件開發周期中越晚發現缺陷，修復缺陷所花費的代價會隨之成倍增長。在開發過程中許多預先的質量檢驗會多占用一點點時間，但是會在以后節約大量時間。這一點已經被許多研究所證實。

　　仍有許多程序設計人員認為找出他們代碼中的錯誤是其他一些人的工作。我發現近十年來這種情況已經有了顯著的改進，但是仍有大量的程序人員并沒有為他們的工作負全責，他們也不使用有助于改進他們代碼的工具和技術。在早期的軟件工程課程中我向我的學生們介紹過單元測試。我告訴他們如何使用現代工具編寫測試。我布置了關于編寫單元測試的作業。然而，當給他們機會在工作中采用有效的單元測試時，只有25%的學生這樣做。原因是什么呢?因為他們還沒有意識到測試的重要性。他們的直覺戰勝了理性。他們知道單元測試的價值，但他們選擇不予理會。

　　單元測試并不需要花費很長時間，但許多程序設計員認為它需要。作為一名教育工作者，我需要努力地在學生們職業生涯的早期就改變這一認識，并在他們整個學習過程中不斷的加以強化。商業組織必須跟上步伐，在他們雇用畢業生時使得單元測試成為一份寶貴的實踐。

　　低效的工具

　　這充其量是一個乏味的借口。在今天有很多有效的單元測試工具可供開發人員們使用。不管您使用的是什么程序語言或者其他的開發工具，單元測試工具都可以供您使用。許多工具都是開源或者免費的。

　　我選擇 Eclipse 作為我的主要開發環境。在我現有的 Eclipse 配置里可以得到的所有單元測試工具中，我主要使用的是 Junit 測試框架。大多數 Java 設計人員都知道 Junit 并且大概至少使用過一次。JUnit 是 Eclipse 的 Java 開發工具中的一個完整部分。這個平臺使得創建 Junit 測試變得簡單。我只需在瀏覽器包里選擇一個 Java 源文件，并在右擊已選文件時從關系菜單里選擇 New>JUnit Test Case(見圖1)即可。提供的支持包括在測試中為類自動創建測試方式以及更多的東西。運行測試和創建一樣簡單。Eclipse 帶有一個獨立的視圖可以觀察 Junit 測試的結果。

原文轉自：http://www.kjueaiud.com