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