The second option for interop is to use P/Invoke. This is accomplished using the DllImport attribute, specifying the attribute on the method declaration for the function you want to import. Marshaling is handled according to how it has been specified in the declaration. However, DllImport is only useful if you have code that exposes the required functions through a DLL export.

When you need to call managed code from native code, CLR hosting is an option. In such a scenario, the native application has to drive all of the execution: setting up the host, binding to the runtime, starting the host, retrieving the appropriate AppDomain, setting up the invocation context, locating the desired assembly and class, and invoking the operation on the desired class. This is definitely one of the most robust solutions in terms of control over what and when things happen, but it is also incredibly tedious and requires a lot of custom code.

The fourth option, and quite possibly the easiest and the most performant, is to use the interop capabilities in C++. By throwing the /clr switch, the compiler generates MSIL instead of native machine code. The only code that is generated as native machine code is code that just can't be compiled to MSIL, including functions with inline asm blocks and operations that use CPU-specific intrinsics such as Streaming SIMD Extensions (SSE). The /clr switch is how the Quake II port to .NET was accomplished. The Vertigo software team spent a day porting the original C code for the game to code that successfully compiled as C++ and then threw the /clr switch. In no time they were up and running on the .NET Framework. Without adding any additional binaries and simply by including the appropriate header files, managed C++ and native C++ can call each other without any additional work on the part of the developer. The compiler handles the creation of the appropriate thunks to go back and forth between the two worlds.

代码生成

输出文件

调试

预处理器

语言

链接

预编译头

杂项

请参见

C/C++ 生成参考 | 编译器选项 | 设置编译器选项

http://www.mailframe.net/Products/TestRunner/default.aspx

TestRunner Provides

• Test Driven Development inside Visual Studio 2005
• Integrated debugging from a simple context menu in the editor
• File, method, and line level code coverage in the editor
• Graphical test feedback directly in the Visual Studio editor
• Console & Trace redirection to the Output Window
• Non-blocking test runs -- program while you test on a background thread
• Test failure tool tips and line markers
• Ultra Performance tested with suites of 1400 unit tests

• TestRunner will change the way you NUnit test by making it a seamless experience with programming. Tests run in the background and richly interact with the Visual Studio editor instead of a separate program, saving you from the window shuffle or losing your place in your code. Unit testing, code coverage, and now performance profiling all in one convenient tool.

cppunit:   http://morningspace.51.net/resource/cppunit/textui.html
 

------------------------------------------------------------------------------------------------------------------------------------

TestDriven.NET网址：http://www.testdriven.net/
下载地址：http://www.testdriven.net/Default.aspx?tabid=27
博客园下载地址：http://downloads.cnblogs.com/TestDriven.NET-1.0.915d.zip
使用帮助：http://www.testdriven.net/Default.aspx?tabid=29

使用感受：
1、与VS.NET集成得很不错, 使用起来很方便, 比如我们运行一个测试方法，直接在这个方法上点击右键Run Test(s):

然后在VS.NET的输出窗口中输出测试结果。Cool! 错误信息会显示在任务窗口。
2、在“解决方案资源管理器”中，可以选中相应的项目点击右键运行测试，可以通过Test With NUnit GUI启动NUnit GUI运行测试。
3、通过Tests With Debugger, 在Debug模式中运行测试，
4、不需要另外安装NUnit。TestDriven.NET已经自带NUnit。

------------------------------------------------------------------

nunit的使用:

http://ltp.cnblogs.com/archive/2005/12/03/289720.html

本页内容

	简介
	分析工具支持
	我们的解决方案
	Visual Studio 中的工具集成
	小结

简介

要开发健壮而可靠的软件，开发人员需要一套集成分析工具，来帮助他们在开发的早期检测代码缺陷和性能问题。

返回页首

分析工具支持

过去，由于 Visual Studio 中缺少对代码分析的支持，因此开发人员不得不购买第三方工具，构建自定义分析工具，或者发布未经分析的代码。

返回页首

我们的解决方案

在 Visual Studio 2005 Team System 中，开发人员将会看到一套全新的、完全集成到 IDE 中的分析工具。这种分析工具与开发环境的紧密集成，可以帮助开发人员在产品开发的早期检测并修复代码缺陷和性能问题。这还可以帮助团队有效且高效地管理软件开发生命周期（Software Development Life Cycle，SDLC）。

在 Visual Studio 2005 Team System 中，有两类分析工具可用于构建健壮而可靠的软件：

在开发环境中集成分析工具可以帮助开发人员检测与编码、性能及安全性相关的问题。此外，可将代码分析工具作为签入策略的一部分用于每日构建 (nightly build) 过程，使开发团队能够在将代码签入到源树 (source tree) 之前修正缺陷。通过在开发的早期（而不是后期）更正问题，团队可降低修复代码缺陷的总体成本。

除了完全集成到 IDE 中之外，开发人员还可以从命令行使用这些工具。

返回页首

Visual Studio 中的工具集成

在 Visual Studio 2005 Team System 中，通过使用代码分析工具和性能工具，开发人员可以对代码进行静态和动态分析。

代码分析工具

代码分析工具的目标是使开发人员能够对其项目进行静态分析，以检测和修复代码缺陷。为了实现这个目标，Visual Studio 2005 Team System 中包含了两个工具：

PREfast

PREfast 是一个静态分析工具，它为开发人员提供有关其 C/C++ 源代码中可能存在缺陷的信息。PREfast 报告的常见代码错误包括缓冲区溢出、未初始化内存、空指针取消引用、内存泄漏和资源短缺。

IDE 集成

为了使开发人员能够自然地使用分析工具，可以将 PREfast 完全集成到 IDE 中。通过在项目的 Property Pages 上选择 Yes (/prefast)，开发人员可以轻松启用 PREfast，如图 1 所示。

图 1. 启用 PRE f ast

在生成过程中，为源代码生成的任何 PREfast 警告都出现在 Error List 中。这些警告包括缺陷路径信息（如果有）；双击突出显示缺陷路径的警告，可以进入代码编辑器中的警告，如图 2 所示。

图 2. PRE f ast 警告

#pragma support

Developers can use the #pragma directive to treat warnings as errors, or disable warnings, as shown below.
#pragma warning (error: 6260)  //treat warning 6260 as an error
#pragma warning (disable: 6011)  //disable warning 6011

批注支持

PREfast 还支持批注以改善代码分析的精确性。批注提供有关函数参数和返回类型的之前和之后条件的附加信息。

#include 
[SA_Post( MustCheck=SA_Yes )] double* CalcSquareRoot
( 
   [SA_Pre( Null=SA_No )] double* source, 
   unsigned int size
)

在上面的示例中：

命令行支持

除了与开发环境完全集成之外，开发人员还可以从命令行使用 PREfast，如下所示。

C:\>cl /prefast Sample.cpp

FxCop

FxCop 是一个静态分析工具，它分析托管代码程序集并报告有关程序集的信息，例如，与 Microsoft .NET Framework Design Guidelines 中阐述的编程和设计规则相冲突。FxCop 表示在分析过程中作为规则执行的检查。规则是一段托管代码，该代码分析程序集并返回有关它发现结果的消息。规则消息识别任何相关的编程和设计问题，并在可能的情况下，提供有关如何修复目标的信息。

IDE 集成

为了使开发人员能够自然地使用分析工具，开发人员可以在项目的 Property Pages 上选择 Run FxCop，如图 3 所示。

图 3. 启用 FxCop

有关包含或排除规则，将规则作为警告或错误的附加选项，也可以在 Property Pages 中找到，如图 4 所示。

图 4. FxCop 规则

一旦启用 FxCop，在生成过程中，FxCop 就会在 Error List 中报告冲突，如图 5 所示。

图 5. FxCop 规则冲突

Error List 提供有关规则冲突的信息和建议，以便于您纠正错误。只需在 Error List 中双击规则冲突，即可轻松地定位到触犯了规则的代码行。

MSBuild 集成

Visual Studio 的下一个版本从根本上改进了生成过程，其方法是引入一个新的、名为 MSBuild 的生成引擎。可以通过 MSBuild 系统调用 FxCop。这使开发人员能够从命令行运行托管项目上的 FxCop。

性能工具

在 Visual Studio 2005 Team System 中，开发人员可以通过性能工具来度量、计算和定位代码中与性能相关的问题。这些工具都完全集成到 IDE 中，以提供无缝、友好的用户体验。

性能工具支持两种分析方法：

在采样的过程中，数据收集基础结构将定期中断正在执行的应用程序，以确定正在执行的是哪个函数，并增加函数的采样计数。它存储有关准备函数调用的调用堆栈的信息。

应用程序退出后，收集到的所有数据会生成为一个报告文件，您可以使用 IDE 中集成的报告功能轻松地查看该文件。

采样的优势在于低开销，因为这只是定期中断应用程序。这使得应用程序的行为能够更接近实际情况。这种方法的缺点是，它只能获取已采样函数的相关性能数据。有可能没有对需要采样的函数进行采样，因而无法获取有关该函数的信息。

使用仪器的优势在于可以收集应用程序的特定部分的精确性能数据。在使用仪器的过程中，“enter”和“exit”探针被插入到应用程序的函数中。这些探针将报告返回给数据收集基础结构，并允许用户捕获函数执行所需的精确时间（或其他衡量标准）。

分析应用程序

分析应用程序的首选使用模式是首先开始采样，然后根据采样所产生的结果检测应用程序的特定方面。

分析应用程序的过程相当简单。首先创建一个新的性能会话。在 Visual Studio 2005 Team System 中，可以使用 Performance Session Wizard 创建一个新的性能会话。

Performance Session Wizard

Performance Session Wizard 设置分析应用程序的必要环境。在 Visual Studio 2005 Team System 中，该向导为 EXE、DLL 和 ASP.NET 应用程序提供内置支持。

可以使用该向导创建一个 New Performance Session，如图 6 所示。

图 6. 启动性能向导

注 要手动创建一个新的性能会话，请使用菜单上的 New Performance Session 命令。可以采用这种方法来手动分析其他类型的应用程序（例如，Windows 服务）。

Performance Explorer

性能会话作为运行会话向导或手动创建会话的结果而创建。Performance Explorer 可以将其直观地表示出来，如图 7 所示。

图 7. 性能资源管理器

Performance Explorer 给用户呈现了层次结构。该层次结构的根节点表示 Performance Session。这种节点的属性是用户在创建 Performance Session 时设置的属性。如果用户使用 Performance Session Wizard 创建会话，则这些属性体现了用户在使用向导的过程中所选择的值。如果用户手动创建 Performance Session，则这些属性包含了它们的默认值。

根节点有两个子节点：Targets 节点和 Reports 节点。Targets 节点包含一个或多个目标，目标可以是 EXE、DLL 或 ASP.NET 应用程序。

Reports 节点包含与某个特定 Performance Session 相关的所有报告。

性能会话报告

一旦应用程序执行完毕，系统就会将一个性能会话报告自动添加到 Reports 节点。可以通过下面的视图来查看这些报告：

Summary 视图

Summary 视图为开发人员提供了其调查的起点。它显示应用程序执行过程中开销最高的函数，如图 8 所示。从该视图中的每个数据点，用户都可以定位到更详细的视图。

图 8. Summary 视图

Functions 视图

Functions 视图显示在应用程序的执行过程中调用的全部函数，这些函数存在于由该应用程序引用的所有模块之中，如图 9 所示。该视图显示的信息取决于所用的分析方法（采样与使用仪器）。

图 9. Functions 视图

Caller/Callee 视图

Caller/Callee 视图提供在 Functions 视图中所列函数的详细信息，如图 10 所示。

图 10. Caller/Callee 视图

Callstack 视图

Callstack 视图使用户能够向下搜索特定的调用跟踪，并分析哪些跟踪对性能的影响最大。

图 11. Callstack 视图

Type 视图

Type 视图提供有关某个特定类型的实例数量和总字节数的信息，如图 12 所示。

命令行支持

可以通过命令行工具使用性能工具功能。这为用户提供了灵活性，用户既可以从命令行运行这些工具，又可以通过脚本来使用它们，以便自动执行任务。

编写可维护的节省时间和精力的单元测试

本页内容

	单元测试的信任
	测试正确的事情
	创建维护测试
	创建易读性测试
	在你的设置方法中避免部分相关的代码
	总结

单元测试的信任

在这个部分，我将略述出一些最通用的信任，这些信任来自于在使用大量单元测试获得的好处和解释为什么这些信任通常不是必须真实的。然后我们会帮助您在您的工程中拥有这些信任。

更加简单的跟踪 Bug  当然这并不是必须的，那么您怎么知道您的测试是正确的？ 是否存在在一些测试环节测试失败的情况？另外您又如何知道您的测试覆盖了系统中多少的代码量？是否测试到了程序中的错误，错误又在哪里等等的问题。

当你在你的单元测试中发现了bug后又会发生什么事情哪？你会突然间得到很多与愿意错误的反馈，bug被发现，但是问题并不在你测试的代码中。你的测试的逻辑存在一个bug，因此测试失败了。这些bug也是您最难被检查出来的，因为您通常会去检查您的应用程序而不会去检测你的测试环节。在这部分中，我会展示给你如何确认大量的单元测试，事实上就是使得跟踪bug变得更加容易。

代码更加便于维护 从最终点考虑，你可以倾向于认为这些信任并不是必须的，当然你是对的，让我们去说，代码中每个逻辑方法至少要有一个测试方法（当然，你可能拥有一个以上的方法）在一个好的测试覆盖的工程中，大概有百分之六十的代码是能够得到单元测试的，现在不得不考虑到测试也是要被维护的，如果针对一个复杂的逻辑方法你有20个测试，那么当你向这个方法添加一个参数时会发生什么事情哪？测试无法编译。当你修改了类的结构的时候同样会发生这样的事情。这时你突然发现为了能让你的应用程序继续工作你自己需要改变大量的测试。当然这会花费你大量的时间。

为了使这个信任确认下来，你需要确认你的测试是便于维护的。保持DRY规则写入：不要重复你自己。我们将更加接近的来看这个问题。

代码更加容易被理解  单元测试的好处通常并非是人们最初所期待的，在一个工程中考虑修改一些你之前从没有看过的代码(比方说,一个特殊的类或者方法).你将如何动手处理这些代码？你可能需要在项目中去浏览这些特定的类或者方法使用的代码，理所当然，单元测试就是这样例子的一个很好的场所。同时，当正确写入的时候，单元测试可以为工程提供一个API文件的容易读取的设置，使得文档的处理和代码的理解对于整个团队中的新老开发者一样的简单，便捷。然而，这些只能在测试是易读的和容易理解的情况下才能被确认，这个规则很多的单元测试开发者并不会遵循。我将详述这个信任，然后在这篇文章的易读测试的部分给你展现如何在去写易读的单元测试。

返回页首

测试正确的事情

新来者在Test Driven Development (TDD)中一个最通常的错误就是他们通常会搞混"Fail by testing something illogical."中的"Fail first"要求。例如，你可以用下面的规格开始这个方法：

' returns the sum of the two numbers
Function Sum(ByVal a As Integer, ByVal b As Integer) As Integer

你可以向如下的方式写一个失败测试：

<TestMethod()> _
Public Sub Sum_AddsOneAndTwo()
    Dim result As Integer = Sum(1, 2)
    Assert.AreEqual(4, result, "bad sum");
End Sub

初看上去这个处理像是一个写失败测试的好的方法，它完全错失了你写错误测试的初始点。

一个失败测试验证了在代码中存在一些错误，当你的测试完成后这个测试应该是通过的，现在的例子中，无论如何，测试都将会失败，即使是代码完成，因为测试逻辑上不是正确的。如果希望测试通过测需要测试自身进行修改――而不是程序的代码的改变（当程序代码改变的时候，是test-first规划的意图）简短来说，这个测试不会反映出程序代码完成后的最终的结果，因此这个不是一个好的测试。

TDD中一个好的测试要求你去修改代码，从而使它能够按照想要的方式工作，这一点要胜于强迫你去反映现在的真实情况或者一个非逻辑要求的渴望的结果。例如，当1＋1返回0时就意味着测试失败。这个简单的例子和这种情况是相似的，在练习中，如果现在的需求是在工作的，测试应该可以反映你所期待的结果，然后你可以调整现在代码的情况去通过这个测试。

作为一个规则，一个已经调通的测试不应该被移除掉，因为这个测试在维护工作中可以用于恢复测试。他们在你改变代码时用来确定你没有损害到现在已经工作的函数。这就是为什么你不应该修改那些已经通过的测试，除非是一些很小的修改，例如增加它的可读性（换句话说，分解测试）

当一个测试非正常失败  有时你可能遇到失败的测试，而这时你对代码的改变是完全合理的。这通常是因为你遇到了冲突的需求。一般来说，可能是一个新的需求（一个改变的特性）与一个旧的可能已经不再有效的需求发生了冲突。这有两种可能：

而有时候一个测试在使用不完整的技术去完成任务的时候也是有效的，例如，你有一个成员类带有一个FOO方法，它表现为某几种行为，它已经经由Test在X年前测试完成，然后现在一些其他的需求加了进来，方法的逻辑增强了，从而可以去处理一些类似于在获取数据时丢失一些参数的异常处理。但这时，突然Test X失败了，虽然在测试这个函数的时候只是使用了同样的类。这个测试的失败是因为在调用方法之前丢失了一些初始处理步骤。

这并不意味着你需要移除Test X，你将丢失对于一些重要功能的测试，这时你应该去关心那些初始化时的问题，而不是改变类的创建以用来适应你新的意图。

当然如果你那里有200个测试都是因为旧的结构导致的失败，你就应该找到这个问题来维护你的测试。这就是为什么你应该总是移除你测试中的副本尤其是在生产代码中。

测试覆盖和测试 Angles  你如何知道是否你的新代码是一个好的覆盖？当试图移动一个链接或者一个约束检查后，如果所有的测试依然通过，那么你就没有足够的代码复制然后你可能需要添加其他的测试单元。

确认你添加正确测试的最好方法就是测试一些最平常的行和检查直到用非常的手段使它出错。这个也许很难，但是如果你不能考虑出一个让代码出错的方法，你就可能没有好的理由在最初的地方写下这行代码。

你不知道什么时候下一个开发者会试图运行你的程序，他可能优化或者错误的删除一些包含本质的行。如果你没有一个测试，它就会失败，其他的开发者可能不会知道他们犯了错误。

你也可能试图利用一些常量去替代一些已经通过了的测试中调用的各种各样的参数，例如，看下面的方法：

Public Function Sum(ByVal x As Integer, ByVal y As Integer, _
        ByVal allowNegatives As Boolean) As Integer
    If Not allowNegatives Then Throw New Exception()
    Return x + y
End Function

你可以打乱代码去测试覆盖，这有一些关于如何测试的变化：

' Try this...
If Not True Then ' replace flag with const
    If x < 0 OrElse y < 0 Then Throw New Exception()
End If

' Or this...
If Not allowNegatives Then
    ' replace check with const
    If False OrElse y < 0 Then Throw New Exception()
End If

如果所有的测试依然通过，那么你缺少了一个测试，另外一个红色标志是在你为多种相同值测试的检查。如下：

Assert.AreEqual(3, retval)

一些方法的关系只看一次（在一个测试中）意味着你可以安全的返回3作为一个值，然后所有的针对这个方法的测试都将通过，这个当然意味着你丢失了一个测试。如果你在单元测试中检查一下代码，它就很容易被检查出来。

确保你的测试写的越简单越好，一个单元测试一般不包括一个if switch或者其他任何的逻辑声明。如果你发现你自己在你的测试中写了一些类似于逻辑声明的东西，这是一个好的机会来测试一个以上的事件，在做这样的操作的时候，你会使得你的测试比读和维护更加的困难，在生产代码中同样如此。保持你的测试简单，你在生产代码中发现bug要胜于在你的单元测试中。

使测试易于运行  如果你的测试并不容易运行，那么人们不会信任它。你的应用程序最有可能有下面两种类型的测试：

第一种类型是你应该模仿的，第二种类型是你通常做的，尤其你如果你是一个新的单元测试。如果你发现你自己测试时有很多的特殊的需求，现在是正常的，但是重要的一点就是你要隔离出两个组让他们能够单独的去做测试。

我们的想法是任意一个开发者都应该有能力修改和运行一些不需要设置特殊的配置的测试进行测试。如果这有一些测试需要在运行前有特殊的关注，开发者应该知道他们，然后他可以花一些时间学习这些测试的方法。因为很多的开发者比较的懒（当然，不是你），你可以设想，他们不会去做那些特殊的设置，相反，他们会让测试失败因为他们有更好的事情去做。

当用户让测试失败时，他们开始考虑他们不能够信任这些测试了。很难说是否测试可以在一个中找到一个正式的bug或者只是一个错误的定位。开发者可能不明白为什么测试者会在一开始就执行失败。一旦他们不再信任你的测试，开发者将会停止运行它们，那么bug就会驻留在程序中，之后一连串的麻烦就来了。。。

为了避免这件事情，确认你总是有一个组准备好了去测试，测试程序则是可以安全运行，可信任的。把那些属于配置挑战组的测试放到不同的文件夹，树或者工程中，同时标记特殊的说明指明他们在运行前需要做什么。完成这些后，开发者可以不投入时间去配置就开始测试工作。当他们有时间和需要时，他们也可以配置，运行更多的测试环节。

返回页首

创建维护测试

我们应该试着避免测试私有或保护成员。这篇文章也许能够帮助一些人解决一部分问题，但是我很坚决相信百分之九十九的时间，你可以全面的测试一个类，通过编写一些与它的独立公共接口相反的单元测试。测试私有成员可以使你的测试更加脆弱，如果这个需要被测试的类的一些内在方面略有改动的话。你应该使用通过调用一些代码里别处的公共功能这一方法去测试私有功能。当你依然能够确定全部功能并没有改变的时候，仅仅测试公共成员会导致测试遭受常量代码的因式分解以及内部的执行情况改变。

在可能的时候，应该重新使用你的创造物，处理过程，和声明代码。不要在一个单元测试中直接的创建类的实例。如果你在任何并不包含在此单元测试框架中的类前面看到这个单词“new”，你应该考虑一下将你创造的代码放在一个特殊的整体方法之中，它可以为你创建一个对象实例。你可以到时再重新使用这个方法来获得你的测试在其他测试之中的最新实例。这样可以帮助你来保持这个测试维护所需的时间，然后在测试进行的时候，从对代码无法预料的改变之中保护你的测试。作为一个例子，Figure 1展示了一对简单的测试，它使用了一个Calc类。

假设你有20，或者你甚至有100，与Calc类做相反测试，所有这些看起来令人吃惊的相似。现在一个计划的改变迫使你不得不删除默认的Calc构造器并且使用一个含有一些参数的不同的构造器。马上，你所有的测试就被暂停了。你可能可以很轻易的发现问题的关键并修复它，但你也可能做不到。最主要的问题是你将会浪费很多宝贵时间在修理你的测试上面。如果你在你的测试类之中使用一个整体的方法去创建Calc 实例，就像Figure 2所显示的那样，这些就并不是个问题。

我已经对测试做了一些改变已使它们能够具有更多可维护性。首先，我将新创建的代码迁移至可以再度使用的整体方法之中。这就意味着我只需仅仅改变一个简单的方法以使得在这个测试类中的所有测试在一个新的构造器中的能够正常的工作。另外一个为创造问题而设的简单解决方法是把创作物迁移到测试类的<TestInitialize()>方法之中。不幸运的是，这个能够很好的工作仅仅在你重新使用一个对象并在一些测试中把它当作一个局部类变量。如果你仅仅为一些测试使用它（部分相关成员），你倒不如在测试中将它们实例化，并且使它们更具易读性。

顺便一提的是，请注意，我已经将方法命名为Factory_CreateDefaultCalc 。我很喜欢将我测试中的任何帮助方法用特殊的前缀来命名，这样我就能很轻易的掌握它是做什么用的。这样对易读性也是非常有帮助的。

我的第二个改变是重新使用测试中的声明代码，并将这段代码迁移到一个确认方法之中。所谓确认方法是你测试中的一个可再度使用的方法， 这个方法包含了一个声明语句但是它可以接受不同输入和在输入的基础上进行校验。当你在不同输入或者不同的初始状态下一次又一次的声明同一事物时，你可以使用确认方法。这一方法的优点是既使在一个不同的方法里面声明，如果这个声明失败了你将可以继续保有一个异常处理，而且原始调用测试将会显示在测试失败输出窗口之中。

我也在Calc 中传递实例而不是使用一个局部变量，因此我知道我经常传递一个实例，而且这个实例是调用测试将其初始化的。当你想要改变对象状态时你可能想要做同样的事情，举个例子来说，当在测试下或者在将会传递给测试的对象下配置特殊对象时，可以使用特殊的Configure_XX方法。这些方法应该能够解释他们配置一个对象将会用来做什么用。Figure 3之中的代码就是以上方法的实例。

这个测试拥有很多设置代码可以用来处理向注册管理器对象中添加初始状态，它是这个测试类之中的成员。在此的确也有一些重复。Figure 4显示了在初始代码之外这些事例在因式分解之后将会如何变化。

修订测试具有非常高的可读性和稳定性。仅仅需要注意的是不要那么的refactor你的测试，他们可能会以一个单一的，不可读的代码行作为结束。应该注意的是我在这里可能依然使用一个Verify_XX 方法，但是这并不是我真正要在这里加以说明的。

消除测试之间的依赖关系

一个测试应该能够自我独立。它不应该与其他测试相关联，也不应该依赖任何具有特殊运行顺序的测试，它应该能够获得你所写的所有测试，可以随意运行所有测试或者只运行其中的一部分，并且是以任何顺序，而且要能够确保它们无论怎样都应该正确的运行。如果你不能够执行这个规则，你将会只在某种特殊的情况下按照预期的表现来运行的状况下结束你的测试。这样子的话，当你在最终期限下与此同时你还想确定你没有向系统之中引进新的问题的时候，当然就会出现问题。你可能很困惑而且考虑着是不是你的代码出现问题，这时，在事实上，问题其实仅仅是你的测试运行顺序所引起的。因此，你可能开始错过了一些在测试中失败的结果而且使它越写越少。这将会是个长期的过程。

如果你从一个测试调出至另一个测试之中，你应该在它们之间创建一个从属关系。你本质上说是在一个测试中测试两个事物（我将会在下一章中解释为什么这会成为一个问题）。就另一方面来说，如果你有测试B，它与测试A 所产生的状态是不相关的，那么你会陷入“顺序”陷阱之中。如果你或者其他人想要改变测试A，测试B将会暂停而且你不知它暂停的原因。对这些故障进行故障处理会浪费很多时间。

使用<TestInitialize()> 和<TestCleanup()>方法是本质上能够获得更好的测试隔离。确定你的测试数据时刻是最新的，而且测试下对象的也具有新的实例，而且所有的状态可以提前预知，而且无论你的测试在任何地方或者任何时间被运行，运行的情况都是相同的。

在一个单独单元测试中避免多重声明

我们将声明故障看作一个程序弊病的象征且声明被当作软件体的指示点或者“血液检查”。你可以找到越多的症状，程序弊病就越可以轻松的被诊断和排除掉。如果你在一个测试中定义了多重声明，只有第一个故障声明将会以抛出异常的方式显示出来。请参考下面插图之中的测试代码：

<TestMethod()> _
Public Sub Sum_AnyParamBiggerThan1000IsNotSummed()
    Assert.AreEqual(3, Sum(1001, 1, 2)
    Assert.AreEqual(3, Sum(1, 1001, 2) ' Assert fails
    Assert.AreEqual(3, Sum(1, 2, 1001) ' This line never executes
End Sub

你可能没有发现以上代码之中其他可能的征兆。在一个故障之后，并发的声明不会被执行。这些不能生效的声明可能提供了有价值的数据（或者征兆）可能能够帮助你很快的集中的焦点而且发现潜在的问题。因此在一个独立的测试中运行多重声明增加了具有很少价值复杂性。另外，声明应该被独立的运行，我们应该设置自我独立的单元测试以使得你具有能够很好的发现错误的机会。

返回页首

创建易读性测试

如果你以前写过单元测试，你是否在单元测试上写了一个好的声明行？可许不是这样的，大多数开发者并不厌烦去写一个好的声明因为他们更加关心去写测试。

假设你是团队中的一个新的开发者，你试图读一个单元测试。连接这个：

<TestMethod()> _
Public Sub TestCalcParseNegative()
    Dim c As New Calc
    Assert.AreEqual(1000, c.Parse("-1, -1000")
End Sub

作为一个简单的练习，如果你理解了上例中Calc分列方法的用法，你很可能可以进行很好的推测，但是他可以简单的作为人员数量的用例使得输出结果为1000:

现在请参考下面在单元测试之中的小改动：

<TestMethod()> _
Public Sub Parse_NegativeFirstNum_ReturnsSumOfTheRestAsPositive()
    Dim c As New Calc
    Dim parsedSumResult As Integer = c.Parse("-1", "-1000")
    Const SUM_WITH_IGNORED_FIRST_NUM As Integer = 1000
    Assert.AreEqual(SUM_WITH_IGNORED_FIRST_NUM, parsedSumResult)
End Sub

这个是不是比较容易理解呢？当声明消息消失之后，表达意图最合适的地方就是测试的名字。 如果你广泛的使用了它，你将会发现你不再需要读测试代码就能明白代码测试的目的所在。事实上，你经常根本不需要写任何注释，因为代码，特别是那些带着实例的，他们自己是证明自己的。

名字包含了三部分内容： 测试下方法的名字（解析），测试下的状态或者规则（带着第一个负数传递一个字符串），以及预期的输出或者运行情况（剩余数字的总和以一个正数的形式返回）。需要注意的是我从名称中将Test以及Calc这两个词删除。我已经知道这是一个属性的测试因此在此没有重复此信息的必要。我也知道这是一个在Calc类中的测试因为测试类经常是写给一个特殊类的（这个类也许已经被命名为CalcTests）。

名字也许会很长，但是又有谁在乎呢？它读起来更像是一个标准英语的句子而且它使得一个新来的开发者更容易明白测试的内容。更是这样，当这个测试发生故障时，我们甚至不需要调试代码就可以知道问题究竟出在哪里。

需要注意的是，我已经在前面分别实际演示了通过在不同行中创建一个结果变量的方法从声明操作中进行分解操作。这样做至少有两个理由。第一个理由是，你可以为一个变量分配一个可读性强的名字，它可以包含结果，这样可以使你的声明行非常易于理解以及易于读。第二点是，测试下与对象相反的invocation 可能非常的长，它可能会使你的声明行延伸出屏幕的边缘之外，这样导致测试者向右滚屏。就我个人而言，我认为这个是非常恼人的。

我在我的测试中使用了很多常量以确保我的声明读起来像一本书。在先前的例子之中，你可以读到声明中说：“确保分解总数是与忽略第一个数后所得总和是相等的。” 为你的变量取一个很好的名字能够在某些程度上弥补对于测试的命名不足。

当然，有时一个声明 消息是在一个单元测试中传递intent的最好的方法。 一个好的声明消息始终能够解释什么因该会发生或者什么发生了而且为什么会出错。举个例子来说，“分列应该忽略掉第一个数字如果这个数字是个负数的话”，“分列不能够忽略掉第一个负数”，还有“X调用对象Y标记错误”这些都是有用的声明消息，它们很清晰的描述了结果的情况。

返回页首

在你的设置方法中避免部分相关的代码

一个<TestInitialize()> 方法是样例成员变量在测试中使用的一个好地方。你所有的测试，只有在一部分的测试中避免变量。他们可以为测试设置本地变量。如果你创建了部分相关的实例作为类的成员，用来在测试中简单的避免创建的副本，你应该使用在文章前面解释的工厂方法，使用部分相关变量使得你的代码和设置方法缺少易读性。一旦变量在一个或者每个测试中使用，那么他应该是<TestInitialize()> 方法的一个成员和变量。

Figure 5 展现了一个拥有两个成员变量的类的测试。但是他们中的一个(cxNum)只被部分使用。Figure 6 展现了如何在测试中替换代码从而使它更加易读的方法。

返回页首

总结

就像你所看到的，写单元测试并不是一个微不足道的任务，如果步骤正确，单元测试可以为开发者的生产力和代码的质量带来令人惊讶的提高，他可以帮助你去创建的应用程序含有更少的错误，同时也可以便于其他的开发者去洞察你的代码，但是他也需要在之前承担一个义务，确认遵循一些简单的规则。当方法并不是很好时，单元测试则可能达到一个相反的结果，从而浪费您的时间，并且使测试过程更加复杂。

Roy Osherove Agile组的负责人, 这个顾问公司致力于agile software development 和 .NET architecture的研究工作. Roy同时维护了一个blog在 www.iserializable.com上有相关的信息. 你可以通过Email联系他： Roy@TeamAgile.com.

转到英文页面

本页内容

	简介
	开始
	创建测试
	运行测试
	检查异常
	从数据库中加载测试数据
	测试视图 (Test View) 窗口
	增加一个测试数据库
	将数据与测试关联
	实现和重构目标方法
	代码覆盖
	初始化和清除测试
	最佳实践
	小结

简介

最新发布的 Visual Studio Test System (VSTS) 包含了一套用于 Visual Studio Team Test 的完整功能。Team Test 是 Visual Studio 集成的单元测试框架，它支持：

另外，Team Test 包含了一套测试功能，可以同时支持开发人员和测试人员。

在本文中，我们准备演练如何创建Team Test 的单元测试。我们从一个简单的示例程序集开始，然后在该程序集中生成单元测试方法存根。这样可以为Team Test 和单元测试的新手读者提供基本的语法和代码，同时也很好地介绍了如何快速建立测试项目的结构。然后，我们转到使用测试驱动开发 (test driven development, TDD) 方法，即在写产品代码前先写单元测试。

Team Test的一个关键特点是从数据库中加载测试数据，然后将其用于测试方法。在演示基本的单元测试后，我们描述如何创建测试数据并集成到测试中。

本文中使用的示例项目包含一个 LongonInfo 类，它封装了与登录相关的数据（例如用户名和密码）以及一些关于数据的简单的验证规则。最终的类如下图 1 所示。

图 1. 最终的 LogonInfo 类

请注意所有的测试代码位于一个单独的项目。这是有道理的，产品代码应该尽可能少的受测试代码影响，所以我们不想在产品代码的程序集中嵌入测试代码。

返回页首

开始

首先，我们创建一个名为“VSTSDemo”的类库项目。默认情况下，为方案创建目录(Create directory for solution) 复选框被选中。保留此选项可以使我们在 VSTSDemo 项目的同一层目录创建测试项目。相反，如果不选中此选项，Visual Studio 2005 会将测试项目放在 VSTSDemo 项目的子目录中。测试项目遵循 Visual Studio 在解决方案文件路径的子目录中创建额外项目的规定。

创建初始的 VSTSDemo 项目后，我们使用 Visual Studio 的解决方案资源管理器将 Class1.cs 文件重命名为 LogonInfo.cs，这样类名也会被更新为 LogonInfo。然后我们修改构造函数以接受两个字符串参数：userId 和 password。一旦构造函数的签名被声明，我们就可以为构造函数生成测试。

图 2. LongonInfo 构造函数的上下文菜单的“创建测试 … ” ( Create Tests... ) 菜单项

返回页首

创建测试

在开始编写 LogonInfo的任何实现之前，我们遵循 TDD 实践的规则，首先编写测试。TDD 在Team Test 中并不是必需的，但最好在本文的剩余部分遵循 TDD。右键单击 LogonInfo()构造函数，然后选择“创建测试…”菜单项(如图 2 所示)。这样会出现一个对话框，可以在不同的项目中生成单元测试（如图 3 所示）。默认情况下，项目设置的输出 (Output) 选项是一个新的 Visual Basic 项目，但是也可以选择 C# 和 C++ 测试项目。在本文中，我们选择 Visual C#，然后单击 OK 按钮，接着输入项目名 VSTSDemo.Test。测试项目名称。

图 3. 生成单元测试对话框

生成的测试项目包含四个与测试相关的文件。

因为我们不打算对该项目进行手工测试，并且由于已经有了一个单元测试文件，我们将删除 ManualTest1.mht 和 UnitTest1.cs。

除了一些默认的文件，生成的测试项目还包含了对 Microsoft.VisualStudio.QualityTools.UnitTestFramework和 VSTSDemo 项目的引用。前者是测试引擎运行单元测试需要依赖的测试框架程序集，后者是对我们需要测试的目标程序集的项目引用。

默认情况下，生成的测试方法是包含以下实现的占位符：

清单 1. 生成的测试方法： ConstructorTest(), 位于 VSTSDemo.Test.LogonInfoTest

   
/// <summary>
   ///This is a test class for VSTTDemo.LogonInfo and is intended
   ///to contain all VSTTDemo.LogonInfo Unit Tests
   ///</summary>
   [TestClass()]
   public class LogonInfoTest
   {
      // ...

      /// <summary>
      ///A test case for LogonInfo (string, string)
      ///</summary>
      [TestMethod()]
      public void ConstructorTest()
      {
         string userId = null; // TODO: Initialize to an appropriate value

         string password = null; // TODO: Initialize to an appropriate value

         LogonInfo target = new LogonInfo(userId, password);

         // TODO: Implement code to verify target
         Assert.Inconclusive(
            "TODO: Implement code to verify target");
      }
}

确切的生成代码会根据测试目标的方法类型和签名不同而有所不同。例如，向导会为私有成员函数的测试生成反射代码。在这种特别的情况下，我们需要专门用于公有构造函数测试的代码。

关于Team Test ，有两个重要的特性。首先，作为测试的方法由 TestMethodAttribute属性指定，另外，包含测试方法的类有 TestClassAttribute属性。这些属性都可以在 Microsoft.VisualStudio.QualityTools.UnitTesting.Framework 命名空间中找到。Team Test 使用反射机制在测试程序集中搜索所有由 TestClass修饰的类，然后查找由 TestMethodAttribute修饰的方法来决定执行的内容。另外一个重要的由执行引擎而不是编译器验证的标准是，测试方法的签名必须是无参数的实例方法。因为反射搜索 TestMethodAttribute，所以测试方法可以使用任意的名字。

测试方法 ConstructorTest()首先实例化目标 LongonInfo 类，然后断言测试是非决定性的(使用Assert.Inconclusive())。当测试运行时，Assert.Inconclusive()说明了它可能缺少正确的实现。在我们的示例中，我们更新 ConstructorTest()方法，让它检查用户名和密码的初始化，如下所示。

清单 2. 更新的 ConstructorTest() 实现

      
/// <summary>
      ///A test case for LogonInfo (string, string)
      ///</summary>
      [TestMethod()]
      public void ConstructorTest()
      {
         string userId = "IMontoya";

         string password = "P@ssw0rd";

         LogonInfo logonInfo = new LogonInfo(userId, password);

         Assert.AreEqual<string>(userId, logonInfo.UserId,
            "The UserId was not correctly initialized.");
         Assert.AreEqual<string>(password, logonInfo.Password,
            "The Password was not correctly initialized.");
      }

请注意我们的检查使用 Assert.AreEqual<T>() 方法完成。Assert方法也支持没有泛型的 AreEqual()，但是泛型版本几乎总是首选，因为它会在编译时验证类型匹配 － 在 CLR 支持泛型前，这种错误在单元测试框架中非常普遍。

因为 UserID 和 Password 的实例域还没有创建，我们需要回头将其添加到 LogonInfo类中，以便VSTTDemo.Test 项目可以编译。

即使我们还没有一个有效的实现，让我们开始运行测试。如果我们遵循 TDD 方法，我们就应该直到测试证明我们需要这样的代码时才去编写产品代码。我们仅在建立项目结构时违背此原则，但是一旦项目建立后，就可以容易地始终遵循 TDD 方法。

返回页首

运行测试

要运行项目中的所有测试，只需要运行测试项目。要实现这一点，我们需要右键单击解决方案资源管理器的VSTSDemo.Test 项目，选择设置为启动项目(Set as StartUp Project)。接着，使用菜单项调试->启动(F5) 或者调试->开始执行（不调试）(Ctrl+F5) 开始运行测试。

这时出现测试结果窗口，列出项目中的所有测试。因为我们的项目只包含一个测试，因此只列出了一个测试。开始的时候，测试会处于挂起的状态，但是一旦测试完成，结果将是我们意料中的失败（如图 4 所示）。

图 4. 执行所有测试后的测试结果窗口

图 4 显示了测试结果 (Test Results) 窗口。这个特别的屏幕快照除了默认的列外，还显示了错误信息。您可以在列头上单击右键并选择菜单项增加/删除列…以增加或者删除列。

如果要查看测试的额外细节，我们可以选定测试并双击，打开“ConstructorTest[Results]”窗口，如图 5 所示。

图 5. 详细的测试 ConstructorTest [ Results ] 窗口

另外，我们可以右键单击单个测试，然后选择打开测试(Open Test) 菜单项，进入测试代码。因为我们已经知道问题在于 LogonInfo 构造函数的实现，我们可以去那里编写初始化 UserID 和 Password 字段的代码，使用传入的参数对它们进行初始化。重新运行测试以验证测试现在可以通过。

返回页首

检查异常

下一步是创建 LongonInfo 类，以提供对 UserID 和 password 的一些验证。不幸的是，UserID和 Password 字段是公共的，这意味着它们没有提供任何封装来确保它们有效。但是在我们将其转换为属性并提供验证前，让我们编写一些测试来验证任何实现的结果都是正确的。

我们首先来编写一个测试，防止空值 (null) 或空字符串赋值给 UserID。预期结果是，如果空值传送给构造函数，会引发一个 ArgumentException异常。测试代码如清单 3 所示。

清单 3. 使用 ExpectedExceptionAttribute 对异常情况进行测试

      
[TestMethod]
      [ExpectedException(typeof(ArgumentException),
         "A userId of null was inappropriately allowed.")]
      public void NullUserIdInConstructor()
      {
         LogonInfo logonInfo = new LogonInfo(null, "P@ss0word");
      }

      [TestMethod]
      [ExpectedException(typeof(ArgumentException),
         "A empty userId was inappropriately allowed.")]
      public void EmptyUserIdInConstructor()
      {
         LogonInfo logonInfo = new LogonInfo("", "P@ss0word");
      }

请注意对于 ArgumentException没有 try-catch 代码块的显式测试。不过，两个测试都包含另外一个属性 ExpectedException，它接受一个类型参数，以及一个可选的错误信息，用于在没有引发异常时显示。当这个单元测试执行时，测试框架会显式地监视引发的 ArgumentException异常，如果方法没有引发这个异常，测试将失败。运行这些测试会证明我们还没有对 UserID 做任何验证检查；因此，测试会失败，因为没有引发预期的异常。

有了失败的测试，现在可以回到产品代码进行更新来提供测试需要检查的功能。在这个例子中，我们将 UserID字段转换为属性，并提供验证检查（清单 4）。

清单 4. 在 LogonInfo 类中验证 UserId

   
public class LogonInfo
   {
      public LogonInfo(string userId, string password)
      {
         this.UserId = userId;
         this.Password = password;
      }

      private string _UserId;
      public string UserId
      {
         get { return _UserId; }
         private set
         {
            if (value == null || value.Trim() == string.Empty)
            {
               throw new ArgumentException(
                  "Parameter userId may not be null or blank.");
            }
            _UserId = value;
         }
      }
      
      // ...
}

属性的实现使用了 C# 2.0 的功能，其中 getter 和 setter 的访问权限不一致。setter的实现标识为私有，而 getter 实现为公有。这样 UserID 就不能在 LogonInfo 类外被修改了（除非通过反射机制）。

一旦增加了验证，我们可以重新运行测试来验证实现是正确的。我们运行所有的三个测试来验证 UserID 字段转换为属性的重构过程没有产生任何意外的错误。单元测试的真正价值在代码修改的时候才真正有所体现。一套单元测试可以保证我们在维护和改进代码的时候没有破坏代码。

返回页首

从数据库中加载测试数据

对于 LogonInfo 类的下一次修改，我们将提供一个方法来改变密码。该方法接受旧密码和新密码作为参数。另外，我们会验证密码符合某种复杂性需求。确切的说，我们将保证密码符合 Windows Active Directory 的默认需求，即包含以下四种类型字符中的三种：

另外，我们将检查密码最少包含 6 个字符，最多包含 255 个字符。

和之前一样，我们在编写实现前先为密码复杂性需求编写测试。但是显然，我们需要提供一个测试值的大集合用于验证实现。我们不是为每个测试用例创建一个单独的测试，也不是创建一个循环来调用一系列的测试用例，我们将创建一个数据驱动测试，它从数据库中取出所需的数据。

返回页首

测试视图 (Test View) 窗口

首先我们定义一个名为 ChangePasswordTest() 的新测试。定义后，从菜单项测试->查看和创建测试(Test->View and Author Tests)为测试方法打开测试视图窗口，如图 6 所示：

图 6. 测试视图 ( Test view ) 窗口

测试视图窗口可用来运行指定的测试和浏览测试的特定属性。通过增加额外的列（右键单击列头并选择添加/删除列…），我们可以排序并根据偏好查看测试。有些列来自修饰测试的属性。例如，添加 OwnerAttribute将在所有者列显示测试的所有者。其它元数据属性（如 DescriptionAttribute）也可以使用。这些属性都可以在 Microsoft.VisualStudio.QualityTools.UnitTesting.Framework 命名空间中找到。如果没有显式的属性存在，那么我们可以使用自由形式的 TestPropertyAttribute来为特别的测试方法增加名－值对。

没有对应列的属性可以在一个测试的属性窗口中显示（选择一个测试，在右键上下文菜单中单击属性）。它包含了指定数据连接字符串和用于载入测试数据的表名的属性。显然，为了指定有效值，我们需要一个数据库连接。

返回页首

增加一个测试数据库

从服务器资源管理器窗口，我们可以使用创建新的 SQL Server数据库(Create new SQL Server Database) 菜单项。但是要小心这种方法，如果我们要在其它计算机上执行测试的话，我们要保证在一台服务器上创建数据库，其它可能执行测试的计算机必须能够访问该服务器 — 例如一台用于构建的计算机。

另外一个选择是仅仅增加一个数据库文件。使用项目->增加新项… (Project->Add new item...) 允许向项目插入一个 SQL 数据库文件。这种方法使测试数据和测试项目保持在一起。缺点是如果数据库变得很大，我们就不想这么做，而宁可提供全局的数据源。

对于本项目中的数据，我们创建一个名为 VSTSDemo.mdf的本地项目数据库文件。为了向文件加入测试数据，我们使用菜单工具->连接到数据库 (Tools->Connect to Database)，然后指定 VSTSDemo.mdf 文件。然后，从服务器资源管理器窗口我们可以使用设计器加入一个新的表 LongonInfoTest。清单 5 显示了该表的定义。

清单 5. LogonInfoTestData SQL 脚本

CREATE TABLE dbo.LogonInfoTest
   (
   UserId nchar(256) NOT NULL PRIMARY KEY CLUSTERED,
   Password nvarchar(256) NULL,
   IsValid bit NOT NULL
   )  ON [PRIMARY]
GO

保存表后，我们可以将其打开，然后输入不同的非法密码，如下表所示。

返回页首

将数据与测试关联

一旦完成表的创建，我们需要将其与测试 InvalidPasswords()联系起来。从测试 InvalidPasswords的属性窗口，我们填写数据连接字符串(Data Connection String) 和数据表名 (Data Table Name) 属性。这样做将使用附加的属性 DataSourceAttribute和 DataTableNameAttribute更新测试。最终的方法 ChangePasswordTest()在清单 6 中显示。

清单 6. 用于数据驱动测试的测试代码

      
enum Column
      {
         UserId,
         Password,
         IsValid
      }

      private TestContext testContextInstance;

      /// <summary>
      ///Gets or sets the test context which provides
      ///information about and functionality for the 
      ///current test run.
      ///</summary>
      public TestContext TestContext
      {
         get
         {
            return testContextInstance;
         }
         set
         {
            testContextInstance = value;
         }
      }

      [TestMethod]
      [Owner("Mark Michaelis")]
      [TestProperty("TestCategory", "Developer"), 
      DataSource("System.Data.SqlClient", 
         "Data Source=.\\SQLEXPRESS;AttachDbFilename=\"<Path to the sample .mdf file>";Integrated 
Security=True", 
         "LogonInfoTest", 
         DataAccessMethod.Sequential)]
      public void ChangePasswordTest()
      {
         
         string userId = 
            (string)TestContext.DataRow[(int)Column.UserId];
         string password = 
            (string)TestContext.DataRow[(int)Column.Password];
         bool isValid = 
            (bool)TestContext.DataRow[(int)Column.IsValid];

         LogonInfo logonInfo = new LogonInfo(userId, "P@ssw0rd");

         if (!isValid)
         {
            Exception exception = null;
            try
            {
               logonInfo.ChangePassword(
                  "P@ssw0rd", password);
            }
            catch (Exception tempException)
            {
               exception = tempException;
            }
            Assert.IsNotNull(exception,
               "The expected exception was not thrown.");
            Assert.AreEqual<Type>(
               typeof(ArgumentException), exception.GetType(),
               "The exception type was unexpected.");
         }
         else
         {
            logonInfo.ChangePassword(
               "P@ssw0rd", password);
            Assert.AreEqual<string>(password, logonInfo.Password,
               "The password was not changed.");
         }
      }

清单 6 第一个需要注意的地方是增加了 DataSourceAttribute属性，它指明了连接字符串、表名和访问顺序。在这个清单中，我们使用数据库文件名标识数据库。这样的优点是该文件和测试项目一起迁移，假设它可能会被移动到一个相对的路径。

第二个注意的地方是 TestContext.DataRow调用。TestContext是在我们运行创建测试向导时由生成器提供的属性，它在运行时由测试执行引擎自动赋值，这样我们就可以在测试中访问跟测试环境关联的数据。如图 7 所示。

图 7. TestContext 关联

如图 7 所示，TestContext提供了 TestDirectory和 TestName数据，以及 BeginTimer()和EndTimer()方法。对 ChangePasswordTest()方法最有意义的是 DataRow属性。因为 ChangePasswordTest()方法由 DataSourceAttribute修饰，该属性指定的表返回每个记录时，该方法都会被调用一次。这就使测试代码使用运行中的测试的数据，而且对插入 LongonInfoTest 表的每条记录重复执行测试。如果表包含四条记录，那么测试将会分别执行四次。

使用这样的数据驱动测试方法，可以很容易的提供额外的测试数据，而不需要编写任何代码。一旦需要额外的测试用例，我们需要做的就是向 LongonInfoTest 表增加关联的数据。尽管我们可以创建两个独立的测试来使用单独的表分别测试有效和无效数据，这个特定的例子合并了这些测试来显示稍微复杂的数据测试实例。

返回页首

实现和重构目标方法

现在我们已经有了测试，是时候为测试编写实现了。使用 C# 重构工具，我们可以右键单击 ChangePassword()方法调用，选择菜单项GenerateMethodStub，然后对于生成的方法提供实现，一旦我们成功地运行了使用所有测试数据的测试，我们也可以开始重构代码了，LogonInfo 类的最终实现如清单 7 所示。

清单 7. LogonInfo 类

using System;
using System.Text.RegularExpressions;

namespace VSTTDemo
{
   public class LogonInfo
   {
      public LogonInfo(string userId, string password)
      {
         this.UserId = userId;
         this.Password = password;
      }

      private string _UserId;
      public string UserId
      {
         get { return _UserId; }
         private set
         {
            if (value == null || value.Trim() == string.Empty)
            {
               throw new ArgumentException(
                  "Parameter userId may not be null or blank.");
            }
            _UserId = value;
         }
      }

      private string _Password;
      public string Password
      {
         get { return _Password; }
         private set
         {
            string errorMessage;
            if (!IsValidPassword(value, out errorMessage))
            {
               throw new ArgumentException(
                  errorMessage);
            }
            _Password = value;
         }
      }

      public static bool IsValidPassword(string value, 
         out string errorMessage)
      {
         const string passwordSizeRegex = "(?=^.{6,255}$)";
         const string uppercaseRegex = "(?=.*[A-Z])";
         const string lowercaseRegex = "(?=.*[a-z])";
         const string punctuationRegex = @"(?=.*\d)";
         const string upperlowernumericRegex = "(?=.*[^A-Za-z0-9])";

         bool isValid;
         Regex regex = new Regex(
            passwordSizeRegex +
            "(" + punctuationRegex + uppercaseRegex + lowercaseRegex +
               "|" + punctuationRegex + upperlowernumericRegex + lowercaseRegex +
               "|" + upperlowernumericRegex + uppercaseRegex + lowercaseRegex +
               "|" + punctuationRegex + uppercaseRegex + upperlowernumericRegex +
            ")^.*");

         if (value == null || value.Trim() == string.Empty)
         {
            isValid = false;
            errorMessage = "Password may not be null or blank.";
         }
         else
         {
            if (regex.Match(value).Success)
            {
               isValid = true;
               errorMessage = "";
            }
            else
            {
               isValid = false;
               errorMessage = "Password does not meet the complexity requirements.";
            }
         }
         return isValid;
      }

      public void ChangePassword(
         string oldPassword, string newPassword)
      {
         if (oldPassword == Password)
         {
            Password = newPassword;
         }
         else
         {
            throw new ArgumentException(
               "The old password was not correct.");
         }
      }
   }
}

返回页首

代码覆盖

单元测试的一个关键度量是决定在单元测试运行时测试了多少代码。该度量称为代码覆盖，Team Test 包含了一个代码覆盖工具，可以详细解释被执行代码的百分率，并突出显示哪些代码被执行，那些没有被执行。该功能如图 8 所示。

图 8. 突出显示代码覆盖

图 8 显示了运行所有单元测试后的代码覆盖的突出显示情况。红色突出显示说明了我们有产品代码没有运行任何单元测试，这说明我们编写这些代码时未遵循 TDD 原则，即在编写实现前先提供测试。

返回页首

初始化和清除测试

一般来说，测试类不仅包含独立的测试方法，还包含了不同的对测试进行初始化和清除的方法。实际上，创建测试向导在创建 VSTSDemo.Test 项目时，将一些这样的方法添加到类 LongonInfoTest 中，见清单 8。

清单 8. 最终的 LogonInfoTest 类

using VSTTDemo;
using Microsoft.VisualStudio.QualityTools.UnitTesting.Framework;
using System;

namespace VSTSDemo.Test
{
   /// <summary>
   ///This is a test class for VSTTDemo.LogonInfo and is intended
   ///to contain all VSTTDemo.LogonInfo Unit Tests
   ///</summary>
   [TestClass()]
   public class LogonInfoTest
   {

      private TestContext testContextInstance;

      /// <summary>
      ///Gets or sets the test context which provides
      ///information about and functionality for the 
      ///current test run.
      ///</summary>
      public TestContext TestContext
      {
         get
         {
            return testContextInstance;
         }
         set
         {
            testContextInstance = value;
         }
      }

      /// <summary>
      ///Initialize() is called once during test execution before
      ///test methods in this test class are executed.
      ///</summary>
      [TestInitialize()]
      public void Initialize()
      {
         //  TODO: Add test initialization code
      }

      /// <summary>
      ///Cleanup() is called once during test execution after
      ///test methods in this class have executed unless
      ///this test class' Initialize() method throws an exception.
      ///</summary>
      [TestCleanup()]
      public void Cleanup()
      {
         
         //  TODO: Add test cleanup code
      }


      // ...

      [TestMethod]
      // ...
      public void ChangePasswordTest()
      {   
      // ...
      }

   }
}

用于对测试进行设置和清除的方法分别由属性 TestInitializeAttribute和 TestCleanupAttribute修饰。在每个这样的方法中，我们可以加入额外的代码，它们将会在每个测试前或者测试后运行。这意味着在每次对应于 LongonInfoTest 表的记录的 ChangePasswordTest()执行前，Initialize() 和 Cleanup() 都会被执行，每次 NullUserIdInConstructor和 EmptyUserIdInConstructor执行时也会发生同样的情况。这样的方法可以用于向数据库中插入默认的数据，然后在测试完成时清除插入的数据。例如，我们可以做到在 Initialize()中开始一个事务，然后在清除时回滚同一个事务，这样一来，如果测试方法使用相同的连接时，数据状态会在每次测试执行完成时恢复原状。类似地，测试文件也可以这样处理。

在调试期间，TestCleanupAttribute修饰的方法可能由于调试器在清除的代码执行前终止运行。由于这个原因，最好在设置测试期间检查清除情况，并在需要时在设置测试前执行清除代码。关于初始化和清除的其它可用的测试属性有 AssemblyInitializeAttribute/AssemblyCleanupAttribute和 ClassInitializeAttribute/ClassCleanupAttribute。程序集相关的属性对整个程序集运行一次，而类相关的属性对一个特定的测试类的加载运行一次。

返回页首

最佳实践

在结束前我们回顾几种单元测试的最佳实践。首先，TDD 是非常有价值的实践。在所有现有的开发方法中，TDD 可能是多年来根本上改进开发且投资成本最小的一种。每个 QA 工程师都会告诉您，开发人员在没有相应的测试前不会写出成功的软件。有了 TDD，实践是在实现前编写测试，并且理想情况是，编写的测试可以成为无需人工参与执行的构建脚本的一部分。需要训练来开始养成习惯，但一旦建立习惯后，不使用 TDD 方法编码就像开车时不系安全带一样。

对于测试本身，有一些额外的原则可以帮助成功进行测试：

返回页首

小结

总的来说，VSTS 的单元测试功能本身很好理解。而且尽管本文没有提到，它还可以通过自定义执行引擎进行扩展。此外，它包含了代码覆盖分析的功能，这对于评价测试的全面性非常有用。通过使用 VSTS，您可以将测试数目和 bug 数目或编写的代码数量进行关联比较。这为项目的运行状况提供了很好的指标。

本文介绍了Team Test 产品中的基本单元测试功能，也探讨了关于数据驱动测试的一些更加高级的功能。通过开始实践对代码进行单元测试，您会为产品的整个生命期建立一套宝贵的测试集。Team Test 通过与 Visual Studio 的强大集成和其它 VSTS 产品线，使这一切变得容易。

Mark Michaelis 在 Itron 公司担任软件架构师和讲师。他曾经对几个微软的产品设计进行检查，包括 C# 和VSTS。现在他正在撰写另外一本有关 C# 的书，Essential C# (Addison Wesley)。不使用计算机时，他会陪伴家人，进行户外运动，或者进行环球旅行。Mark Michaelis 住在 Spokane, WA。您可以通过 mark@michaelis.net 和他联系或者访问他的网络日志：http://mark.michaelis.net。

转到原英文页面

翻译者Luke是微软公司的软件工程师，习惯使用C++和C#开发应用程序。闲暇时间他喜欢音乐，旅游和怀旧游戏，并且愿意帮助MSDN翻译更多的文章和其他开发者共享。可以通过ecaijw@msn.com联系他。

在日常的编程中，程序员经常离不开的工作之一，就是调试。当写好一段代码或程序后，在运行后总会出现这样那样的问题，比如各样的错误，程序员就必须进行调试，将这些错误排除。在最新出炉的Visual Studio 2005中，将提供十分强大而方便的调试功能，从而使程序员能节约时间，提高工作效率。本文中，将主要介绍Visual Studio 2005 在调试方面新增加的几个重要功能，并介绍它们的简单用法。
　　
　　Edit and Contiue功能

　　在调试程序的时候，经常会遇到这样的情况：在调试一大段代码时，遇到了一个小的错误，比如参数的赋值错误了，这时候，往往希望能够马上将这些小的错误改正过来后，能够继续调试跟踪下去，而不用结束整个调试过程去修改。在Visual Studio 2003中，我们必须停止当前的调试，修改错误的地方，再重新编译，这样十分不方便。在Visual Studio 2005 中，提供了一个新的功能叫"edit and continue"，意思是说，当你在调试时，遇到小的错误需要马上修改后，可以进行编辑修改，然后继续往下调试，不需要结束整个调试的过程，当你修改后，调试器在后台进行了自动的编译，并且会执行新修改的代码，十分方便。下面举个例子进行说明。 

　　打开Visual Studio 2005,使用c#建立一个winform窗体应用程序，在窗体中添加一个label标签，一个文本框，一个按钮，如下图所示，我们要实现的功能是，在文本框输入一些信息后，点按钮，会弹出一个消息框，显示的是刚才输入的信息。
    


 假如我们编写的代码如下所示，出现了一个小错误，把textbox1.text的内容当作字符串的一部分了，所以显示不出用户输入的信息。