為你寫代碼
我曾經提到，我已經包含了一個連同它的單元測試一起的真正單元。Bugslayer.Utility.DLL是一個我已經在項目之間拖拽的有用代碼集合。 ArgParser類是一個命令行論據分析類，這個類是基于在舊的.NET Framework SDK WordCount例子中的類。SystemMenuForm類是一個Windows窗體，這個窗體允許你在系統菜單中附加項目和作為常規時間回應點擊操作。
我之所以編寫GlobalMessageBox是因為每次使用一個消息框時我非常厭煩看到代碼分析錯誤， Specify MessageBoxOptions。規則規定當使用一個消息框時，你需要瀏覽類，然后明確是否RightToLeft屬性被設置為Yes。如果是，你必須調用合適的MessageBox.Show負載在MessageBoxOptions標記里通過。GlobalMessageBox為了我而關心這個，抑制錯誤和允許我的代碼在右到左的語言系統中正確的工作。
對于Bugslayer.Utility.DLL的完全單元測試位于Bugslayer.Utility\ Tests\ Bugslayer.Utility.Tests目錄中。在各種各樣的CS文件中包括39個測試，提供了超過92％的代碼覆蓋。由于這是一個 Windows 窗體的單元，此單元提出了消息框和控件，你不能夠無人參與的運行它，但是它能夠在15秒之內運行。
對于Bugslayer.Utility.DLL的完全單元測試位于Bugslayer.Utility\ Tests\ Bugslayer.Utility.Tests目錄中。在各種各樣的CS文件中包括39個測試，提供了超過92％的代碼覆蓋。由于這是一個 Windows 窗體的單元，此單元提出了消息框和控件，你不能夠無人參與的運行它，但是它能夠在15秒之內運行。
名稱和位置
MSTEST.EXE最不成對的部分就是它的輸出命名規范。如果你使用/RUNCONFIG選項來操作一個 TESTRUNCONFIG文件，輸出文件將使用在那個文件中規定的命名規范。如果你不使用/RUNCONFIG，或者設置為默認，所有的輸出被寫到.\ TestResults\< user>_<machine> <timestamp>。我建議使用能夠快速識別的名稱。
MSTEST.EXE提供了/RESULTSFILE選項，但是這將導致輸出文件名稱丟失時間戳。另外，如果指定到 /RESULTSFILE的文件名稱退出，MSTEST.EXE將會失敗。我所希望的就是指定一個我所集中工作的細節的名稱，但是不需要手動的添加時間戳。
你可能會想可能的解決方法就是使用VSMDI測試源數據文件，這個文件你過去在測試管理器窗口中看到。事實上，MSTEST.EXE沒有/TESTMETADATA選項來加載和運行測試。問題是你僅僅能指定一個VSMDI文件。
一個可能的解決方案就是創建一個單獨的VSMDI文件，這個文件在你的代碼里面導入所有其它的VSMDI文件。那的確可以工作，但是它也呈現出另外一個維護任務來回憶每一次你添加新的測試到代碼中。
值得注意的是當運行VSMDI文件時你不能夠告訴IDE或是MSTEST.EXE將輸出文件放在什么位置。輸出文件指向了VSMDI文件貯存的目錄。建議在一個目錄中保存測試，這個目錄在版本控制里源代碼之下，以致如果你共享項目，所有的測試代碼將會跟隨它。
由于VSMDI文件作為每一次測試的一部分，并且沒有一種方式來集中輸出，輸出將圍繞著你的源代碼被分散。這并不是一個很大的處理，但是它意味著你必須手動的整理源樹。在處理一些測試運行結果之后，我想要一種簡單的方法來處理這個。
一個更好的MSTEST.EXE
基于此次論述，我明白了有四個特性我想添加到MSTEST.EXE。第一個是一種方法用來動態的發現所有的單元測試，然后就像小的smoke測試一樣運行它們。第二個是一個簡單的方法用來識別出相似的測試運行而不僅僅是讀時間戳。第三個就是確保所有的測試輸出定位到一個單一的位置。最后，我想要一種非常容易的方法來除去無關的測試運行而不管它們在源樹中的什么位置。
這些需求強烈要求MSBuild。Bugslayer.Build.Tests.DLL中的MSTestTask包裝MSTEST.EXE所以你能夠獲得所有的控制。就像你看到的代碼，你將注意到它是從ToolTask類獲得的，并且是由 Microsoft.Build.Utilities.DLL程序集產生的。當編寫一個包裝了一個命令行工具（因為它做了大部分的提高）build任務時，這個任務，ToolTask就是你想要使用的。
對于一些工具，你所需要做的就是定義你唯一的屬性，重載三個方法和一個屬性。屬性是ToolName，它返回了工具的可執行名稱。 GenerateFullPathToTool方法返回了完全的驅動，路徑和文件名稱到工具本身。為了驗證這些參數，你需要重載 ToolTask.ValidateParameters方法，如果一切正常的話，返回值為真。為了編譯真實的命令行到工具中，重載 ToolTask.GenerateCommandLineCommands然后使用CommandLineBuilder類或者是我對它做的簡單的擴展 ExtendedCommandLineBuilder。
為所有可能的命令行參數運行MSTEST.EXE/?。當它指定輸出文件名稱的時候需要ResultsFile。你也需要設置TestMetaData參數或者TestContainer參數以此分別的顯示出源數據文件或者測試容器。
為所有可能的命令行參數運行MSTEST.EXE/?。當它指定輸出文件名稱的時候需要ResultsFile。你也需要設置TestMetaData參數或者TestContainer參數以此分別的顯示出源數據文件或者測試容器。
但是，我對于MSTestTask的長期計劃就是擴展測試屬性以允許通配符能夠為測試名稱的執行被通過。那將允許你容易的執行僅符合具體前綴的那些測試。借助在TestContainer屬性中被通過的程序集，這工作將僅僅是一系列的反射，查找擁有 TestClassAttribute的類庫和一些符合規范表達的帶有TestMethodAttribute的方法。
MSTestTask其他的操作部分來自于RunTests.Targets文件，你可以在.\Build包含源代碼的目錄中找到這個文件。它包括了非�？岬腅xecuteAllTests對象，這個對象在你指定的目錄中開始，在整個結構中查找所有的單元測試， GenericTests，WebTests 和OrderedTests，然后執行它們。你可以認為ExecuteAllTests對象對于單元測試是一個來說自動衰退測試。當你添加新的測試時，它將自動的執行它們。在代碼下載中包含的RunTests.Targets代碼非常明智的使用排除文件來獲得我們希望的東西。為了查看一個使用中的 RunTests.Targets例子，查看一下SmokeTest.proj，它為所有的代碼顯示出smoke測試。
在.\Build目錄中最后的TARGETS文件是MSTestCleanUp.Targets。就像它名稱所暗示的那樣，它的職責就是查找包含 TestResults的所有目錄作為一個路徑然后刪除它們。它是使用轉換的一個很好的例子，就像MSBuild中的RemoveDuplicates任務一樣。使用MSTestClean-Up.Targets，你就不用怕其他的文件毀壞你的源目錄。
掩飾，包裝
如果你不說，我將對Visual Studio 2005中新的單元測試工具非常興奮。像ASP.NET和DataGrids這樣的程序在此書中受到了所有的關注，但是當你努力按時獲得程序時，測試工具將會帶來很大的影響。我可以保證，你在使用測試工具上花費的時間越多，你的代碼將會變的更好。
Tip 73 你可以控制一個單元測試默認的編程語言和當一個新的單元測試被單元測試向導創建后哪些條目能被添加到里面。來到選項對話框，擴展測試工具節點，然后轉到測試項目屬性頁面。在那，你將看到默認的測試項目類型combobox和每個語言類型的默認文件選擇。如果你像我一樣，在你創建了第二個單元測試后你將清除 “About Test Projects”介紹文件。
Tip 74 試圖將一個程序集中的所有的單元測試保存到一個單一的測試程序集。那個一對一的映射來自于維護的觀點。但是，當程序集增長時，測試數量將會變得非常大。我喜歡將前綴放到測試方法的名稱上，因為這個它們測試的特性有關。這樣可以很容易的分組。例如，在Bugslayer.Utility.Tests.DLL 程序集中，關于GlobalMessageBox類的測試開始于”GNB_”
文章來源于領測軟件測試網 http://www.kjueaiud.com/
