VSTS2005單元測試功能的全自動化
Team版的VS2005里面包含了完整的Test功能,具體有:Unit Test,WebTest和LoadTest.這一整套的測試基本涵蓋了軟件開發會使用到的測試功能.
VSTS2005單元測試介紹
我這里先從單元測試開始介紹(Unit Test).說起單元測試,很多使用.net進行開發的人員也許馬上就想起了NUnit,實際上它是個很好的工具,在VS2005出來之前,我也一直使用.不過現在VS2005已經提供了與NUnit一樣,甚至還要強大的功能,我們又有什么理由不使用呢?
OK,進入正題.首先我們要解決一個問題,為什么我們需要做單元測試?這個問題,對有經驗的老程序員來說,并不算是問題.一個軟件在開發的過程中,倘若不是非常微型的軟件,那么我們通常會劃分出若干個功能模塊來,然后一個模塊一個模塊的進行開發.每個子模塊完成后,我們并不知道它是否能正常的運行,尤其是當這個模塊只是個中間件類似的代碼塊,那么我們為了減少之后可能出現的問題和debug的難度(可以想象,如果在整合時期進行測試或者是甚至還有其他的模塊需要依賴該模塊才能進行開發的時候,盡早的測試將會是非常的重要),我們常常會對這單個模塊進行測試,比如寫段小程序,人為的寫入幾個參數來調用組件等.不用懷疑了,這就是單元測試.我相信,大部分的程序員都做過這樣的工作,而且也許還有許多程序員就如我上面所說的,單獨寫段小程序來進行單元測試(我自己以前也是如此),現在我們需要認真考慮下下一個問題了:如何進行高效的,高可靠的,甚至自動化的單元測試?
VSTS里的Unit Test可以幫助我們實現我們希望的絕大多數功能.我們從實際的項目開發入手來介紹.假設我們新建了一個.net項目,嗯,這是一個有關緩存的子項目,名字叫MyCache.我們很認真的設計了項目的架鉤,進行了可行性分析,接口和抽象的建立,具體對象的建立,關系建立,最后編碼完成了.項目經理叫我們不要高興的太早,他要求我們必須對這個項目進行可靠的單元測試,因為這個子項目非常重要,將會被許多項目引用.盡管我們很有信心,但是沒有辦法,我們依然需要進行單元測試.我們使用了Visual Studio Team System開發了這個項目,于是我們理所當然的使用自帶的Unit Test工具進行單元測試.
VSTS2005單元測試實現步驟
Step1.我們需要建立項目文件與測試文件的映射關系.
難道要我們去手動創建嗎?這可是整個項目啊,里面也許包含了幾十個類,數百個方法…當然沒那么復雜!實際上,我們需要做的工作很少,只是動動鼠標,等幾秒就可以了:)
在VS2005的IDE環境下,選擇menu里的Test,繼續選New Test項,這時將跳出個窗體,里面可以選擇測試項目類型,這里我們選擇Unit Test Wizard,確定,輸入測試項目名,然后將又出現一個窗體,里面包含你當前的solution里的所有project,我們選上我們的MyCache, 確定.OK,看見一個進度條,這是在執行測試代碼的映射工作,等結束后,你就會發現,已經建立了一個測試項目了,里面的文件完全對應你的目標項目,每個類包含的方法也是與目標類的方法一一對應,非常簡單,cool,mission complete!
Step2.運行我們的測試項目.
接下來,我們怎么進行測試呢?里面有許多的類和方法,很多方法上還帶有像TestMethod這樣的標簽屬性,但是我們關心的是,如何進行測試?絕對不是通常的F5來運行:(,在VSTS里,單元測試實際上有專門的管理工具.再次選到menu上的Test選項,移到windows上展開自菜單,里面有好幾個選項,我們選擇TestManager打開.在IDE窗口內出現了一個視圖結構的東西,在分割線的右邊是一個listView,里面全是當前測試項目包含的方法,我們隨便選幾個方法給勾上,右鍵,Run Checked Test,下邊馬上有出現了Test Result窗體,里面就是剛才你選擇的方法.如果不出意外的話,你的這個窗體內的方法result應該都是failed之類的數據,嗯,先不管這個,最起碼,我們已經運行了一次測試項目了,雖然有些奇怪,不過我們已經知道了如何運行一個測試項目了,那么再進入下一個step吧:)
Step3.看看我們的測試代碼里都有些什么.
雖然知道了怎么運行測試項目，但莫名其妙的全部出錯,是怎么回事呢?我們進入測試項目具體的代碼來看看.
我們會發現,每個測試類的名稱就是對應的目標類的名稱+"test",里面的方法也是如此,如果是構造函數,則是諸如
ConstructorTest或ConstructorTestN這樣的形式,N為重載次數.每個方法里面的代碼看上去也不奇怪,只是構造參數來調用而已,最后通過斷言來判斷(用過NUnit的朋友不會陌生吧?).我們試著直接把一個方法里的斷言去掉看看,編譯,TestManager,run,嘿,果然,去掉斷言的方法就pass了!看來蒙老大不難呢,只要把所有的方法的斷言都給去掉,然后給老大看測試后的結果,呵呵…
Step4.深入的了解一下方法上帶有的屬性的含義.
每個方法上幾乎都帶有TestMethod這個屬性,我們直覺告訴我們,這肯定是表示被測試函數的意思.事實也正是如此,在Unit Test里,有許多測試屬性,常用的如下:
| 屬性 | 描述 |
|
TestClass() |
該屬性表示一個測試裝置。 |
|
TestMethod() |
該屬性表示一個測試用例。 |
|
AssemblyInitialize() |
在執行為執行選擇的第一個 TestClass() 中的第一個 TestMethod() 之前，執行帶有該屬性的方法。 |
|
ClassInitialize() |
帶有該屬性的方法在執行第一個測試之前調用。 |
|
TestInitialize() |
帶有該屬性的方法在執行每個 TestMethod() 之前調用。 |
|
TestCleanup() |
帶有該屬性的方法在執行每個 TestMethod() 之后調用。 |
|
ClassCleanup() |
帶有該屬性的方法在執行 ALL 測試之后調用。 |
|
AssemblyCleanup() |
在執行為執行選擇的第一個 TestClass() 中的第一個 TestMethod() 之后，執行帶有該屬性的方法。 |
|
Description() |
提供關于給定 TestMethod() 的描述。 |
|
Ignore() |
由于某種原因忽略 TestMethod() 或 TestClass()。 |
|
ExpectedException() |
當測試特定異常時，如果使用該屬性指定的異常不是從實現代碼引發，則測試不會失敗。 |
需要注意的是,上面的屬性不是可以適用于所有方法的,比如AssemblyInitialize()和ClassInitialize()是必須是靜態方法的屬性.
我們可以把初始化的操作放在他們里進行.
Step5.修改測試方法及其斷言.
到現在,我們的思路開始清晰起來了,我們要開始做真正的測試了,不是僅僅去掉斷言就pass那么簡單了:)
我們的測試思路應該是這樣:我們調用該方法,需要傳入什么值,會影響什么值,當它執行之后,會產生怎樣的期待值?我們把期待值與實際的值想比較,同時寫下斷言失敗的message.
還是以我們的MyCahce為例,假如我們有個ListCache類,里面有個AddItemToTop(item)方法,表示把一個item插入到當前鏈表的頭部.我們實際的測試函數該這么寫
Guid id = System.Guid.NewGuid();
Item item = new Item(id);
list.AddItemToTop(item);
Assert.AreEqual(id, roomList.FirstLinkedItem.Key, "插入后查詢獲得的key值與插入的對象的key值不相等!");
通過比對插入后的鏈表的頭部的key與之前保存的key值來判斷,這是不是一次成功的插入.
這只是個很簡單的例子,我們當然應該根據具體的方法需要實現的功能來定義測試代碼.
Step6.OVER
完成了上面5部,相信你已經對VSTS的Unit Test非常的熟悉了,接下來需要做的就是把你需要的測試的method都提供正確的測試代碼,注意,這里我們甚至不要考慮我們本身的項目究竟有沒有實現該功能,但我們應該該知道,我們需要什么功能.我們只針對應該產生的結果寫測試代碼.當測試不通過時,我們只需要修改我們的目標項目,而不再需要修改我們的測試項目.這其實正是TDD(測試驅動開發)的思想,我們如果要驗證我們的方法有沒有錯,只需要run一下test即可,真正實現了全自動化單元測試, 這里邊的實際開發效率的提高,只有你在真正體會過后才能明白:)
以上就對VSTS2005單元測試進行了一番介紹。
【編輯推薦】
