密切注意Hardcoded路径
使用单元测试向导在一个新的项目上添加测试是一件非常容易的事情。这个便利的特点可以节省你数百个小时的打字时间（微软的开发者为此应收取很多费用）。但是，一些事情在幕后发生了，并且导致你很悲伤：路径是hardcoded！这是一个问题，例如，当你移动一个测试到另一台机器或是目录时就会发生。我希望一个Visual Studio 2005的Service Pack允许你为测试设置一个开始路径，hardcoded路径将使用相对路径。目前，但是解决hardcoded路径的容易方式就是在团队中有一个慈善的独裁者，它总是判断和颁布所有的驱动和路径。如果它是一个小的项目，这种解决方案是很好的。另一个，一些实用的工作区在你的路径中将引用% testdeploymentdir%环境变量。当测试运行时它被设置。
Hardcoded路径出现的第一个地方就是在VSMDI文件中，这个文件是一个大的包装皮里面包含简单的测试列表。当你打开一个VSMDI文件，然后它不能找到测试集或者TESTRUNCONFIG文件，你将被提示为这些项目指出位置。我发现有意思的事情是下一次我再打开相同的VSMDI文件时，它会发现所有的东西。很明显，更新的路径一定存储再某个地方，但是VSMDI文件本身并没有被改变。我再VSMDI文件驻留的目录中发现一个隐藏文件，名称为 name.VSMDI.OPTIONS。
当我打开VSMDI.OPTIONS文件时（它是一个常见的XML文件），我摇晃我的头，感觉受挫一样。就像你在Figure 1中看到的一样，在VSMDI文件中很明显的有路径搜索的支持，但是在Visual Studio用户界面中没有一种方式可以设置搜索的路径。（此外，对这些VSMDI文件来说没有理由被隐藏啊。）所以，当我想在一个不同的目录结构中使用 VSMDI文件时，首先复制一个示例的VSMDI.OPTIONS文件到适当的目录，然后手动的编辑它，在程序集和TESTRUNCONFIG文件中添加路径。为这一部分的源代码，我已经在BaseVSMDIOPTIONSFile文件夹中示例出了一个文件。
使用VSMDI文件主要的原因就是你可以指定要运行的测试列表－在动态开发过程中它是非常有用的，因为它允许你运行这些具体的测试，这些测试与你工作使用的代码相关。在一个测试集中要运行所有的测试，你可以使用控制台测试运行器，MSTEST.EXE。在这有大量的命令行选项，但是你仅仅需要” /testcontainer”选项，它指定了包含在测试中的程序集。另外，你可以使用”/resultfile”来指定结果文件的名称。当使用 MSTEST.EXE时，你不必担心VSMDI文件。在下一部分，我将论述一个MSBuild.EXE任务，它可以自动的运行在目录结构中发现的所有测试，所以你可以避免和VSMDI文件一起使用。
你发现hardcoded路径的第二个位置就是在TESTRUNCONFIG文件中；指向instrument和strong key文件的程序集就包含hardcoded路径。我曾经指出了解决这个问题最好的办法就是当你在不同的目录结构下运行测试时使用一个不同的 TESTRUNCONFIG文件。因为没有办法创建一个新的TESTRUNCONFIG文件，你需要复制一个已经存在的文件到机器位置，然后使用 Visual Studio编辑它。如果驱动和上一级目录不同，IDE和MSTEST.EXE讲使用相关的路径来处理TESTRUNCONFIG文件，但是，你必须手动的编辑它们。
因为它本身不是做代码覆盖的测试工具，所以没有办法阻止为来自命令行的已经编译的程序集手动的执行代码覆盖。如果你使用ASP.NET进行工作，你需要从Visual Studio集成开发环境中做代码覆盖来创建合适的工具集，然后使它成为工具。
手动的做代码覆盖是一个三步的过程。第一步就是实现程序集以致你在它们中拥有代码覆盖钩（hooks）。第二步就是开始监视进程，然后告诉它在哪编写覆盖文件。任何在监视进程运行时加载的已经实现的二进制将它们的覆盖数据添加到输出文件。最后一步就是关闭监视，编写CONVERAGE文件。我已经制作出一个Converage.Targets文件，你可以和MSBuild一起使用来自动化这个过程。Figure 2显示出一些文件；您可以从MSDN®Magazine网站下载到全部的文件。
当你浏览Figure 2时，你将看到在Bugslayer.Build.Task.DLL中我写了一个任务来运行监视进程。Figure 3在Visual Studio中显示了它。
文章来源于领测软件测试网 https://www.ltesting.net/
