Visual Studio 2010 中的單元測試法

　　集團正打算為接近完成的應用程序創建一個單元測試。我們要通過多個登錄用戶運行這些測試，而且還不知道如何從單獨的測試類中做到這一點。另外一些幾乎相同的測試也只是存在數據輸入和輸出的差異。我們可以重復利用這些測試中的代碼嗎?我們只創建了50個測試，不過啟用測試的條件已經丟失。在這種情況下，我們集團怎樣才能在創建大量測試之后繼續往下走呢?我們已經在網上了解過單元測試的相關信息，但是其中大部分都是側重于系統架構，而系統架構是我們所不能更改的?？峙挛覀冎荒芊艞墕卧獪y試了，但是管理規定要求有完整的代碼覆蓋。 怎樣使用Visual Studio中的T4代碼生成工具

　　專家解答答：不要放棄單元測試!單元測試的發展歷史尚淺。正是因為這個原因，在本文給出的回答中給出的建議不會冗繁。這里我們所提供的是適用于所有項目的實用型單元測試。如果你想在測試中實現系統設計結構化，那你想對了，因為被簡單測試過的設計和演變設計這兩者關系很近。你不可以進行測試，除非你進行了測試驅動型開發并且具備一個可以承受失敗的架構。

　　測試已有架構和系統要求指定一個匹配系統的測試方法。一些設計從單元測試的角度看來似乎是可測試的，不過還是要依賴手動測試。這些設計將業務邏輯放到用戶界面中。假設你的邏輯已經存在于業務層，下一個測試問題則來自粒度和數據庫訪問。直接的數據庫訪問意味著測試性能被大大減緩，數據庫的更改中斷了測試，也破壞了實際代碼，當然測試數據必須被保存。

　　我們假設你遇到了所有這些問題。保存測試數據最簡單的方法就是在每次運行時都重新創建數據庫，并將其作為測試的一部分。雖然這樣做會減緩測試，但是如果每天都有測試那么不如將測試交給夜構建(Nightly Builds)。并不是說這種做法很完美，但是它可以讓你擺脫測試的壓力，讓你專注于編寫測試。我們必須在數據庫發生更改時，與數據庫同步保存所有測試。測試設置可以在長達幾周的開發過程中被完全棄用，除非這些更改是實時發生的。

　　我們可能會認為測試比較特殊，然后選擇不按平時對待代碼的方法來對待它，不過測試仍然是代碼，我們要向對待其他代碼一樣給予足夠重視。對象設計，重復利用，有意義的命名和高質量的代碼對于單元測試都很重要。 Visual Studio 2010中的災難恢復功能

　　首先，要問的問題是：“對象可以做什么?”以及“為什么它是一個單獨的對象?”由VS創建的測試文件提供了一種假象，即測試類的目的是為了測試位于測試下的單獨類?？焖贆z查測試聲明中使用的屬性會發現其真實意圖是為一套測試，運行測試和解除測試條件等設定條件，屬性標記方法，如ClassInitialize，TestIntialize，ClassCleanup，TestCleanUp和TestMethod。當然你不能從一個單獨類測試多個用戶——生成代碼或許暗示可以這樣做，但是這個類的設計意圖并非如此。在這種情況下，最簡單的方法是利用為每次登錄所設計的不同類。

　　重復利用在測試中很重要。尋找重新構建代碼以減少冗余的機會，適當的時候可以使用內置的幫助代碼。例如，不同登錄情況下可以使用相同的基類。

　　另一個在測試期間可以最大限度提高代碼重復利用的技巧是數據驅動型測試。當你執行這種測試的時候，該技巧或許與你所使用的數據庫并無關系。它可以讓你通過外部機制聲明輸入和輸出的數值，并鞏固那些只通過輸入和輸出值來區分的測試。你可以使用任意ODBC資源，包括SQL Server。筆者更喜歡Excel，因為它支持測試裝置添加更多測試條件。你需要訪問TestCentext，編寫測試以便使用測試數據并確保其執行：

[TestClass] 　　public class TestClass 　　{ 　　public TestContext TestContext {get; set;} 　　[TestMethod] 　　[DataSource("System.Data.OleDb", 　　@"Provider=Microsoft.Jet.OLEDB.4.0;Data 　　Source=TestData.xls;Extended Properties='Excel 　　8.0;HDR=Yes;IMEX=1';", 　　"Sheet1$", DataAclearcase/" target="_blank" >ccessMethod.Sequential)] 　　[DeploymentItem("TestData.xls")] 　　public void TestMethod() 　　{ 　　int x = Convert.ToInt32(TestContext.DataRow["x"]); 　　int y = Convert.ToInt32(TestContext.DataRow["y"]); 　　int result = Convert.ToInt32(TestContext.DataRow["Result"]); 　　Assert.AreEqual(result, Class1.AddValues(x,y), "Addition is not correct"); 　　} 　　}

　　TestCentext允許對測試環境的訪問，包括數據源。數據源指向名為TestData的Excel電子表格，該表格包含名為Sheet 1的工作表。符號$作為Excel命名的一部分被添加。該表格包含了欄目標頭x，y和Results，這些都可以在調用Assert之前設置變量。

　　進行數據測試型測試的時候，數據部署是個令人頭疼的問題。VS測試通常不能在本地運行，但是可以被復制到測試目錄中。這樣就可以插入代碼以便測量代碼覆蓋并保障任意本地資源，如文本文件沒有在測試期間被更改的時候。由于測試期間必須提供數據，所以必須將數據部署到臨時目錄中。DeploymentItem屬性賦予了文件名稱，它應該作為測試環境的一部分執行。文件名包含了相對路徑，在這一例子中，路徑相對于建成的可執行文件。為了將電子表格放在可知性文件目錄中，可以將其包含在項目中，并將其設置為Output Directory目錄以隨時復制。如果你運行測試裝備編輯電子表格以創建額外測試，一定要保護數據文件，這可以通過把它放置在源代碼控制中實現。

　　組織大量測試并將測試與項目期望聯系起來是具有挑戰性的。一個新出現的重要技術遵守的是Rspec等工具所使用的命名模式。該方法記錄了什么情境會通過明確規定的條件來測試。例如，這些類可能是：

[TestClass()] 　　public class When_an_admin_is_logged_in 　　... 　　[TestClass()] 　　public class When_a_normal_user_is_logged_in 　　... 　　[TestClass()] 　　public class When_any_user_is_logged_in 　　...

　　類的初始化會記錄相應用戶，然后運行一系列授權測試。這些測試反應了你的實際測試情況：

[TestMethod()] 　　public void User_class_CanCreate_property_is_true()

　　你可以想象得到完全基于反射的報告是怎樣。根據你的授權規則，這一測試可能屬于admin或any_user測試類。你或許想用有創意的命名方式來描述系統的設計方式。如果授權基于架構，例如該測試或許是any_user類中的property_matches_configuration。多數情況下，你可以通過從相同基類中獲取同一類，從該類中受保護方法中運行真實代碼以及執行終端類中的Asserts等方法來改善重復利用。

　　避免過長名稱很容易，但是你永遠不能調用這些方法——只能在測試輸出內容和記錄中讀取方法。完整句法結構有助于創建標準，這樣，不同人創建的測試名稱會基本一致。

　　在文章開篇的問題中提到測試條件，并稱管理對代碼覆蓋很感興趣。代碼覆蓋是一種可怕的數據，與按照代碼行數來衡量效率比起來它好不到哪里去。代碼覆蓋不能確定系統是否經過很好的測試，因為它不能考慮限制條件和其他可能導致失敗的故障點。覆蓋唯一指明的是哪些代碼沒有經過測試。首先要對代碼進行的操作不是覆蓋，而是確保它的使用。如果代碼被使用了，要確定相應的假設情景并添加更多測試。

原文轉自：http://www.anti-gravitydesign.com