我之所以编写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方法，如果一切正常的话，返回值为真。为了编译真实的命令行到工具中，重载
文章来源于领测软件测试网 https://www.ltesting.net/
