当首次编写Civerage.TARGETS时，我使用Exec任务执行VSPERFCMD /START:Coverage /OUTPUT:$(OutputCoverageFile)，但是在做这时有一个严重的错误，MSBulid.EXE在调用时完全的挂起了。 VSPERFCMD.EXE产生出了真实的监视进程，VSPERFMON.EXE。如果你在命令提示符下运行VSPERFMON.EXE，进程将待在那吐出连接和进程中其它活动的信息，所以你不能从项目文件中直接的调用它。
这个问题出现在MSBuild.EXE中，滋生于某个事件，这个事件就是VSPERFMON.EXE从带有bInheritHandles标记的 VSPERFCMD.EXE进程中产生到CreateProcess，并且设置为“真”。任何带有继承句柄开始的进程将在MSBuild.EXE下挂起。因此，我必须在任务中从ITask.Execute方法调用Process.Start，通过这样操作才能使MSBuild.EXE下的所有事情正常运行。
与GenericTest和EXEs一起合作
如果你已经获得一个基于EXE程序的存在的测试系统，在文档中GenericTest类型的论述可能伤害您的好奇心。当在一个依赖运行九个EXE作为单元测试的批处理文件的项目上进行工作时，我可以使用GenericTest类型快速的包装一些自动化过程中存在的代码。虽然这也有一些catch。第一个小的障碍就是GenericTest允许0作为一个成功的来自EXE的返回值。那并不是一个很大的处理，但是考虑到GenericTest的高级特性，我很沮丧的看到与可接受的退出代码区域一样简单的事情被遗漏了。
GenericTest的一个比较大的问题就是它是hardcoding的一个堡垒。幸运地，可以容易地指出相对路径地文治。如果你地 GenericTest存在C:\FOO中，事实上测试将从C:\FOO\TestResults\_< Machine>_\Out开始。这样，如果被GenericTest执行地EXE文件在C:\FOO中，你可以使用./././.EXE作为程序来执行。不幸地是，几乎GenericTest中地其他事情从驱动器中被硬编码。有趣地是外部目录就是你地二进制每次运行时被复制到地地方。即使你改变了代码，你可以重新运行测试地以前版本以重新生成问题。
一个便利地特性，GenericTest类型将捕获定位到标准输出地任何事情，在结果文件中提供一个运行日志。不幸的是，这看上去像是一个捕获的问题，在那提取一些信息将导致测试驱动进程挂起。但是大部分测试程序在几秒中内不会抽空输出结果中的100行。
创建单元测试
当提到测试，Visual Studio真正的魔力就是当你在编辑器里右击一个方法时，它可以奇妙的创建你得到的单元测试选项。这个特性非常好，可以很容易的快速添加单元测试。但是，我遇到了一个小的哲学问题，它让你创建可以直接进入类并且访问私有方法的单元测试。
针对允许测试工具直接调用私有的或受保护的方法的争论就是它减化了测试（只写很少的代码），并且帮助扩宽了代码覆盖。这些争论是很诱人的，但是我同意这个观点，就是认为单元测试应该仅仅通过公共接口出现。单元测试是代码的首次使用，你想朝着其他的怎么使用它的方向来调整测试。如果有一些私有方法，这些方法你在没有short circuiting和直接的调用它们的情况下不能充分的测试，我必须知道是否代码需要被注册。为了阻止偶然的创建一个直接调用私有方法的单元测试，找到创建单元测试对话框，在右上角点击过滤，然后清空显示非公共项目。
我决不是一个绝对论者。我确定有一些示例，在示例里面它将帮助调用私有方法。但是，仅因为工具允许你做一些事情并不意味着你将依赖它。单元测试是测试的第一阶段，它也是你开始white box测试的第一个位置。
使用NUnit
我有一些项目，在项目中我们已经在一个扩充NUint的测试系统做出了很大投资。（对.NET Framework 2.0起作用的新版本即将被发布）在一个示例中，我们想要代码在NUnit和Visual Studio测试系统之间是便携式的。当计划这个时，我偶然发现很酷的一些事情，那就是需要最少的代码改变，并且允许代码与NUnit和Visual Studio一起工作。
我有一些项目，在项目中我们已经在一个扩充NUint的测试系统做出了很大投资。（对.NET Framework 2.0起作用的新版本即将被发布）在一个示例中，我们想要代码在NUnit和Visual Studio测试系统之间是便携式的。当计划这个时，我偶然发现很酷的一些事情，那就是需要最少的代码改变，并且允许代码与NUnit和Visual Studio一起工作。
#if !NUNIT
using Microsoft.VisualStudio.TestTools.UnitTesting;
#else
using NUnit.Framework;
using TestClass = NUnit.Framework.TestFixtureAttribute;
using TestMethod = NUnit.Framework.TestAttribute;
using TestInitialize = NUnit.Framework.SetUpAttribute;
using TestCleanup = NUnit.Framework.TearDownAttribute;
#endif
我所需要做的就是使用NUnit测试属性改变我的方法为TestMethod，然后我就有一个在两种方式下工作的测试代码。
TimeOutAttribute
包含决大部分属性的文档固然非常好。但是，最重要的属性之一，TimeOutAttribute并没有包含在API文档中。当TESTRUNCONFIG 文件允许你指定单元测试的全部超时值时，TimeOutAttribute让你指定一个单独的测试可能花费的最大毫秒数。我发现 TimeOutAttribute在这些联系数据库的测试方法上没有价值，所以我密切注视这些查询。请注意，时间值包含一些测试运行器的时间。另外，机器的速度和性能将影响时间。使用你的测试进行实验来看一下时间选择是怎么在你的系统上工作的。
TestContext类我们只是简要的涉及到，它也是被单元测试向导添加进来的TextContext属性。主要的论述是关于当你正在使用 DataSourceAttribute时通过使用TestContext类获得数据行。TestContext类有很多内容提供。文档显示出 TestContext类标记为抽象，但是事实上支持你的单元测试的源类型是UnitTestAdapterContext，它来自于 Microsoft.VisualStudio.QualityTools.Tips.UnitTest.Adapter.dl，你可以在< Visual Studio .NET install dir>\Common7\IDE\PrivateAssemblies 中发现这个DLL文件。你可以使用.NET Reflector查看UnitTestAdapterContext以此明白它是如何工作的。
或许这个类支持的最重要的方法就是WriteLine，你可以使用它添加额外的输出到单独的测试结果中。所有的编写都将出现在报告的额外信息部分。为了发现什么测试正在运行或测试开始于什么目录，你可以单个使用TestContext属性域TestName和TestDir。最后，如果你想为所有或部分测试设置时间器，调用TestContext.BeginTimer和TestContext.EndTimer。在标准的控制台输出部分，时间数据将显示在测试运行结果中。
为你写代码
文章来源于领测软件测试网 https://www.ltesting.net/
