我之所以編寫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>_
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方法，如果一切正常的話，返回值為真。為了編譯真實的命令行到工具中，重載
文章來源于領測軟件測試網 http://www.kjueaiud.com/
