在您的数据库项目中应用测试驱动的开发

核心提示： 本文讨论: TDD 的优点 在数据库开发中应用单元测试 组合 T-SQL 与 .NET 兼容的语言 连接、测试条件和事务本文使用了以下技术:Visual Studio 2008, SQL Server目录 软件开发中的单元测试数据库单元测试定义连接管理 T-SQL 脚本修改生成的测试代码事务System.Tr

本文讨论:

TDD 的优点

在数据库开发中应用单元测试

组合 T-SQL 与 .NET 兼容的语言

连接、测试条件和事务

本文使用了以下技术:

Visual Studio 2008, SQL Server

目录

软件开发中的单元测试

数据库单元测试

定义连接

管理 T-SQL 脚本

修改生成的测试代码

事务

System.Transactions

数据驱动的测试

自定义测试条件

定义测试条件

修改测试执行

展望

LMicrosoft 于 2006 年 11 月发布了 Visual Studio® Team System Database Edition，也称为 DBPro 或 Data Dude，它向产品生命周期方法中引入了数据库开发。DBPro 还引进了数据库单元测试设计器，使用它可以轻松地生成或编写面向 T-SQL 的单元，在开发前验证数据库对象。在本文中，我将深入阐述数据库单元测试，解释运用功能的方法，展示如何对您自己的数据库项目执行单元测试。

软件开发中的单元测试

在软件开发中，单元测试在确保质量水平和满足里程碑要求方面发挥着重要的作用。尽管很多开发人员均认可单元测试的重要性，但他们大都不会在产品周期结束时花费时间编写单元测试。为解决这一问题，测试驱动开发 (TDD) 方法应运而生。开发人员可以使用这种方法在实际运用功能前编写单个功能的单元测试。这样，开发人员就可以从外到内查看 API，尽可能简化设计。

如今，众多使用 C# 和 Visual Basic® 的开发人员均以 TDD 为指导，通过创建单元测试在尚未编写的类上试用方法，然后利用最少量的代码编译测试。如果编译后的测试失败，开发人员只需编写通过下一轮测试所必需的代码即可。每次迭代时均运行所有单元测试来验证没有出现回归错误。应用程序和单元测试代码随后签入源代码控件。每个单元测试针对所开发的方法运行两次。

为充分发挥作用，单元测试在其运行前必须设置自身的执行环境，以便稳定地验证其专门测试的代码。实施并验证测试后，将其签入源代码控件并在产品生命周期的其余部分使用，以确保按预期继续使用方法。

由于您需要提供稳定的测试环境以便在签入更改前验证代码，TDD 也因此在数据库开发中变得更具挑战性。为了让数据库单元测试成功运行，它必须具备合适的架构和数据。这意味着为运行测试，其他开发人员在创建单元测试时必须重用您所使用的环境。如果没有大量造价高昂的基础结构，这一点很难实现。幸运的是，DBPro 能让身处这一环境的开发人员遵循相同的单元测试流程。

从源代码控件中获得最新的测试和数据库项目，然后将新存储的过程加入数据库项目中。配置过程的输入和输出参数。

右键单击新存储的项目，然后选择“create unit tests”（创建单元测试）。将单元测试添加到现有的测试项目中。新测试类加入带有 T-SQL 的测试项目，T-SQL 将使用默认输入参数执行新存储的过程。

修改输入参数以包含预期值，然后添加测试条件以验证存储的过程是否返回了预期的结果。

运行测试。进行测试设置时，将数据库项目部署到本地的 SQL Server® 实例中，并执行数据生成计划以用预期的测试数据填充新部署的数据库。针对本地 SQL Server 实例执行测试，测试会失败（这是预期的结果，因为存储过程的逻辑尚未执行）。

执行存储过程的逻辑并再次运行测试。部署更新后的存储过程并通过测试。

运行所有测试来验证数据库，然后将存储的过程和单元测试代码签入源代码控件中。

DBPro 提供的功能包括：从现有的函数、存储的过程或触发器生成存根 T-SQL 单元测试；自动将数据库项目更新部署到沙箱实例中；使用数据生成计划在测试环境设置过程中生成数据；以及针对目标数据库执行 T-SQL 测试。尽管这些功能可一起使用，但并不要求必须这样做。例如，可以从头编写数据库单元测试，不必在每个测试运行前都生成数据。

数据库单元测试

数据库单元测试功能反映了在某种程度上相互竞争的两个目标：数据库开发人员希望使用熟悉的 T-SQL 脚本表达单元测试逻辑，并希望利用 C# 或 Visual Basic 这样面向 Microsoft® .NET Framework 的强大语言。通过在 T-SQL 代码中封装测试，然后在 C# 或 Visual Basic .NET 代码中托管 T-SQL，这两个竞争目标得以协调。单元测试设计器两者兼俱，可以修改其中的任何一个（或两个）来满足单独的需要。

如果您是设计自己的数据库测试架构，带有 Team System 的数据库单元测试提供或支持您想要的功能。您需要使用合适的上下文执行测试。例如，您需要在连接数据库时利用 Web 层将使用的凭据，或在执行测试前后能使用另一组凭据访问或修改基础表。能够在运行“测试组”中的每个测试之前和之后运行脚本来设置或重置数据库状态很有帮助，它等同于在测试前后能够运行单个测试的脚本来设置或重置数据库状态。

最后，您可以通过添加您数据库专用的条件来扩展可用测试条件组，利用事务控制对数据库状态的修改并使用数据推动多次运行具有不同输入和输出参数的测试。在某些情况下，您还需要其他代码才能使用这些功能。让我们来了解一下必需的步骤。

定义连接

如前所述，数据库测试工具可以不使用验证和设置数据库时的连接而使用其他连接执行测试，这一特点十分重要。为达此目标，Microsoft 创建了连接上下文这一概念，其中包含定义连接及其在执行测试时使用方式涉及的所有必要信息。基本连接上下文包括创建其他 ADO.NET 对象时所用的开放式连接、提供程序工厂 (msdn2.microsoft.com/system.data.common.dbproviderfactory) 及执行测试时使用的超时和 DbTransaction。

使用上下文类型可定义两个上下文实例：执行上下文和有权限的上下文，以支持测试设置、执行和验证。从名称上可以清楚地看出，执行上下文用于执行单元测试。它应代表使用数据库的应用程序配置。有权限的上下文用于验证单元测试并执行所有其他修改操作（包括部署和数据生成）。这两种上下文的定义存储在随附示例测试项目的 app.config 文件中一个专为数据库单元测试定义的区段内。

管理 T-SQL 脚本

从代码角度而言，数据库单元测试生成 C# 或 Visual Basic .NET 代码，它们在 Visual Studio 中构建单元测试框架。在单元测试框架中，使用一个类做为容纳测试的容器（每个测试定义为一种方法）。有多种机会可以在单元测试设计器中添加脚本以支持我曾阐述的脚本功能。除测试脚本外的其他所有脚本均使用有权限的上下文执行，因为它们是专门用于设置或验证测试环境的。脚本可能会执行一次或多次，具体视其添加的位置而定，因此让我们来了解一下脚本的细节和执行方式（请参见图 1）。

Figure1共享的测试条件配置

脚本	执行
测试初始化	此 T-SQL 脚本用于在每次测试执行前设置测试环境。在类中的每次测试前均执行此脚本。
测试前设置	执行具体测试前的设置您可使用测试前脚本对测试进行设置，或验证数据库是否已为测试做好准备。
测试	测试本身。
测试后清理	执行具体测试后的清理。测试后脚本供您恢复或验证数据库状态之用。
测试清理	此 T-SQL 脚本用于在完成测试后恢复测试环境。每次测试后均执行此脚本。

现在，让我们看一下如何在数据库单元测试设计器中创建、访问或修改脚本。首先从“Test”（测试）菜单中选择“New”（新建）测试来创建数据库单元测试，然后选择数据库单元测试模板。完成向导中的步骤后，您将会看到提示您配置项目的对话框，现在将其取消（随后再加以讨论）。在解决方案资源管理器中，将新建一个名为 DatabaseUnitTest1 的文件，并打开相关的设计器供您创建第一个单元测试。

在图 2 中有三个区域值得注意。首先是左上方的下拉列表，您可以从中选择类中定义的通用脚本和测试。创建新的测试类时，会将名为 DatabaseTest1 的默认测试加入类中；您可使用“Rename”（重命名）按钮重命名此默认测试，并使用带有绿色加号的按钮添加其他测试。

图 2新单元测试

您可以在该按钮左侧的下拉列表中切换脚本。如果在左侧的下拉列表中选择了通用脚本，则可以编辑每次测试前后运行的测试初始化/清理脚本。另一方面，如果选择了“测试”，则可编辑前期/测试/后期脚本。

第三，您可使用“测试条件”面板访问基于 T-SQL 脚本执行结果工作的测试条件，以此验证结果是否与您的预期相符。单击超级链接“Click here to create”（单击此处创建）后，会启用下拉列表。通过下拉列表可以访问在您机器上注册的测试条件。

正如您从 UI 中看到的，所有脚本的模式均相同。您可以在任何位置定义脚本，也可以定义一个或多个测试条件，用它们验证脚本是否如期执行。编写单元测试代码时，脚本的验证至关重要。只执行一段代码是不够的，您还需要验证执行能否产生预期的效果。

此时，您可能会有所疑问：测试如何知晓连接哪个数据库以及我指出的有权限上下文的具体含义。答案是：您需要返回我先前让您取消的那个对话框。要返回该对话框，请选择“Test Project”（测试项目），然后转至“Test”（测试）|“Database Test Configuration”（数据库测试配置）（请参见图 3）。

图 3配置单元测试

在第一个下拉选项中，选择将用于执行测试的连接字符串。此连接字符串默认将可能使用 Windows® 身份验证，但您可以指定 SQL Server 身份验证。如果是这样，将输出并加密密码，然后将其存储在注册表内（测试执行期间会从注册表中检索密码）。

在第二个下拉列表中，指定修改和验证数据库状态使用的另一组凭据。例如，如果您想使用应用程序所用的凭据执行测试（比如，与数据库通信的 Web 层），您可能要使用另一组权限更高的凭据，以便验证数据库状态。所有其他脚本（包括部署和数据生成）均使用此连接字符串。如果您未指定连接字符串，则使用执行连接字符串。

在第三个下拉列表中，选择要在执行任何测试前部署的数据库。如果选择数据库项目（并选择了默认配置），将执行差异构建并将更改部署到执行连接字符串中指定的数据库内。如您未做出任何更改，这是一种快捷操作（归功于 DBPro SP1 中的更改），因为 MSBuild 和部署脚本会检测到没有做出任何更改。测试执行完毕后，您可通过单击“测试结果”工具窗口顶部的超级链接来查看数据库部署的结果。

在最后一个下拉列表中，选择在执行测试前应部署的数据生成计划。由于每次运行测试时均将执行此计划，因此您要配置少量的数据以减少实际开始执行花费的时间。

单击对话框中的“OK”（确定）后，信息将存储在测试项目的 app.config 文件中，如图 4 所示。至此，我已向您展示了 UI 包含的主要功能，现在开始深入地探讨实际代码。

Figure4app.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
　<configSections>
　　<section name="DatabaseUnitTesting"
　　　type="Microsoft.VisualStudio.TeamSystem.Data
　　　　.UnitTesting.Configuration.DatabaseUnitTestingSection,
　　　　Microsoft.VisualStudio.TeamSystem.Data.UnitTesting,
　　　　Version=9.0.0.0, Culture=neutral,
　　　　PublicKeyToken=b03f5f7f11d50a3a" />
　</configSections>
　<DatabaseUnitTesting>
　　<DataGeneration ClearDatabase="true" />
　　<ExecutionContext
　　　Provider="System.Data.SqlClient"
　　　ConnectionString="Data Source=(local)sqlexpress
　　　　;Initial Catalog=Database1Sandbox;Integrated
　　　　Security=True;Pooling=False"
　　　CommandTimeout="60"/>
　　<PrivilegedContext
　　　Provider="System.Data.SqlClient"
　　　ConnectionString="Data Source=(local)sqlexpress
　　　;Initial Catalog=Database1Sandbox;Integrated
　　　Security=True;Pooling=False" />
　</DatabaseUnitTesting>
</configuration>

修改生成的测试代码

单元测试 API 旨在让您能够更改或扩大测试工具的现用工作方式。Microsoft 预见到用户可能需要修改生成的代码、编写其自己的测试条件并用自己的实现取代默认测试服务。图 5 列出了构成数据库单元测试 API 的类。（详细信息另请参阅 msdn2.microsoft.com/microsoft.visualstudio.teamsystem.data.unittesting。）

Figure5数据库单元测试 API 中的类

类	用途
TestCondition	用于验证测试脚本的所有测试条件的基础类。组件的子类，支持设计时和运行时执行。在设计时，您使用在测试执行期间预期的值配置测试条件；在运行时，测试条件使用这些值验证实际的测试结果。
DatabaseTestClass	Visual Studio 中所有数据库单元测试的基础类。此类的定义集成在 Visual Studio 设计环境中，负责在 InitializeComponent 中序列化代码。
ConnectionContext	将连接封装到数据库。
DatabaseTestActions	此类是一个组件，数据库单元测试的设计时表示。此类的实例托管包含一个测试的 DatabaseTestAction 实例。
ExecutionResult	代表测试执行过程中一个批量执行的结果。
DatabaseTestAction	此类是一个组件。它的实例包含脚本和测试条件集。
DatabaseTestService	测试工具的默认实现。它实现数据库部署、数据生成、执行创建和有权限连接上下文以及测试执行。

通过 DatabaseTestClass 的静态属性访问测试服务的默认实例。如果您希望，可以用自己的实现替换默认实现，并覆盖上述任何实现。

有几个原因可能促使您修改生成的 Visual Basic 或 C# 代码。最常见的两种情形是在事务中执行单元测试或利用单元测试工具的数据驱动测试功能。

事务

在共享环境中执行的单元测试必须注意不要损坏执行环境；修改预期的数据或架构可以导致后续测试异常失败。数据库单元测试的作者尤其需要小心，因为极易出现此类错误。

这就是说，数据库单元测试的作者通过使用事务来避免修改基础数据库，这种方式对于任何数据库开发人员而言都是习以为常了。在此我将为您演示三种可以利用事务的方法。在执行的 T-SQL 内，使用此事务：

begin transaction
　-- Execute test
　-- We can clean up when the test passes successfully; otherwise, it
　-- is up to the engine to clean up the transaction when the
　-- connection is closed
rollback transaction

在 ADO.NET 事务中，执行图 6 中所示的代码。要使用 System.Transactions，请参看图 7。

Figure7使用 System.Transactions

[TestMethod()]
public void SystemTransactionsExample()
{
　using (TransactionScope transactionScope =
　　new System.Transactions.TransactionScope(
　　TransactionScopeOption.Required))
　{
　　base.ExecutionContext.Connection.EnlistTransaction(
　　　Transaction.Current);
　　base.PrivilegedContext.Connection.EnlistTransaction(
　　　Transaction.Current);
　　DatabaseTestActions testActions = this.SystemTransactionsExampleData;
　　
　　// Execute the pre-test script
　　Trace.WriteLineIf((testActions.PretestAction != null),
　　　"Executing pre-test script...");
　　ExecutionResult[] pretestResults = TestService.Execute(
　　　this.PrivilegedContext,
　　　this.PrivilegedContext,
　　　testActions.PretestAction);
　　// Execute the test script
　　Trace.WriteLineIf((testActions.TestAction != null),
　　　"Executing test script...");
　　ExecutionResult[] testResults = TestService.Execute(
　　　this.ExecutionContext,
　　　this.PrivilegedContext,
　　　testActions.TestAction);
　　// Execute the post-test script
　　Trace.WriteLineIf((testActions.PosttestAction != null),
　　　"Executing post-test script...");
　　ExecutionResult[] posttestResults = TestService.Execute(
　　　this.PrivilegedContext,
　　　this.PrivilegedContext,
　　　testActions.PosttestAction);
　}
}

Figure6ADO.NET Transaction

[TestMethod()]
public void ADONetTransactionSample()
{
　base.ExecutionContext.Transaction =
　　base.ExecutionContext.Connection.BeginTransaction();
　try
　{
　　DatabaseTestActions testActions = this.ADONetTransactionSampleData;
　　// Execute the test script
　　Trace.WriteLineIf(
　　　(testActions.TestAction != null),
　　　"Executing test script...");
　　ExecutionResult[] testResults = TestService.Execute(
　　　this.ExecutionContext,
　　　this.ExecutionContext,
　　　testActions.TestAction);
　}
　finally
　{
　　base.ExecutionContext.Transaction.Rollback();
　}
}

在这三个选项内，如果您不使用前期/后期测试脚本设置数据库或验证测试结果，则 T-SQL 和 ADO.NET 事务发挥作用；切记，前期/后期脚本使用不同的连接执行，因此它们的修改无法复原。使用 System.Transactions 时，已经创建了有权限连接和执行连接，因此它们必须在实例化 TransactionScope 时创建的环境事务中登记，但所有更改均可回滚。

System.Transactions

由于使用环境事务（如先前的 System.Transactions 中所示）是最全面的解决方案，让我们进一步了解其中的细节。（您也可访问 msdn2.microsoft.com/ms172152 了解更多背景信息。）由于环境事务要跨两种不同的连接使用，而这两种连接可能具有不同的生存期，因此必须使用分布式事务处理协调器 (DTC) 服务来管理事务的生存期。这意味着为使用 System.Transactions，必须启动数据库的 DTC 服务才能通过测试。如果未启动服务，测试将失败，并出现类似如下所示的异常：

Test method TestSamples.DatabaseUnitTest1.SystemTransactionsExample threw exception:
System.Data.SqlClient.SqlException: MSDTC on server '(LOCAL)SQLEXPRESS' is unavailable.

修改每种方法以使用环境事务相当的乏味，您更有可能想要将所有的事务测试归组到一个类中，然后修改这个类以便为每个测试启动和停止事务（请参见图 8）。

Figure8对每个测试使用事务

TransactionScope _ambientTransaction;
[TestInitialize()]
public void TestInitialize()
{
　// Create the transaction prior to the
　// connections being created.　When the
　// connections are created they will
　// automatically enlist in the transaction
　ambientTransaction = new TransactionScope(
　　TransactionScopeOption.Required);
　base.InitializeTest();
}
[TestCleanup()]
public void TestCleanup()
{
　// Since Complete() was not called, disposing
　// of the ambient transaction will cause all
　// changes to be rolled back
　ambientTransaction.Dispose();
　base.CleanupTest();
}

数据驱动的测试

您可使用 Visual Studio 2005 附带的测试工具多次运行单元测试，每次使用不同的输入参数组。此工具的使用说明文档可在以下两个位置找到：msdn2.microsoft.com/ms182527 中的“编写数据驱动的单元测试的代码”和msdn2.microsoft.com/ms243192 中的“演练：使用配置文件定义数据源”。

数据库单元测试 API 允许您为 Execute 方法提供零个或多个 DbParameter 实例，从而支持数据驱动的测试。为了解所提供的 DbParameter 实例的使用方法，将 SQL 测试脚本视为参数化的 SQL 可以直接引用 DbParameter 实例做为代码中的变量。图 9 显示了一个示例。

Figure9提供 DbParameter 实例

[DataSource ("System.Data.SqlClient", "Data Source=(local)sqlexpress" +
　";Initial Catalog=TestDB_DataDriven;Integrated Security=True",
　"DecisionAllocationTestData", DataAccessMethod.Sequential), TestMethod()]
public void DataDriveTestSample()
{
　// Setup and execute the test
　DatabaseTestAction test = new DatabaseTestAction();
　DbParameter customerID = CreateParameter(
　　"@customerID", DbType.Int32,
　　ParameterDirection.Input, "CustomerID");
　DbParameter offerID = CreateParameter(
　　"@offerID", DbType.Int32,
　　ParameterDirection.Input, "OfferID");
　DbParameter decision = CreateParameter(
　　"@decision", DbType.StringFixedLength,
　　ParameterDirection.Input, "Decision");
　DbParameter actualVault = CreateParameter(
　　"@vault", DbType.Int32,
　　ParameterDirection.Output);
　DbParameter actualBroker = CreateParameter(
　　"@broker", DbType.Int32,
　　ParameterDirection.Output);
　DbParameter actualMarket = CreateParameter(
　　"@market", DbType.Int32,
　　ParameterDirection.Output);
　test.SqlScript = @"
　　declare @rc int
　　execute @rc = AllocatePositionsByDecision
　　@customerID,
　　@offerID,
　　@decision,
　　@vault out,
　　@broker out,
　　@market out
　";
　
　DatabaseTestClass.TestService.Execute(
　　base.ExecutionContext, base.PrivilegedContext,
　　test,customerID, offerID, decision, actualVault,
　　actualBroker, actualMarket);
　// Verify the results
　int expectedVault = (int) base.TestContext.DataRow["ExpectedVault"];
　int expectedBroker = (int)base.TestContext.DataRow["ExpectedBroker"];
　int expectedMarket = (int)base.TestContext.DataRow["ExpectedMarket"];
　Assert.AreEqual(expectedVault, actualVault.Value, "Vault incorrect");
　Assert.AreEqual(expectedBroker, actualBroker.Value, "Broker incorrect");
　Assert.AreEqual(expectedMarket, actualMarket.Value, "Market incorrect");
}
private DbParameter CreateParameter(string paramName,
　DbType paramType, ParameterDirection paramDirection)
{
　return CreateParameter(paramName, paramType, paramDirection, null);
}
private DbParameter CreateParameter(string paramName,
　DbType paramType, ParameterDirection paramDirection,
　string dataColumnName)
{
　DbParameter newParameter =
　　base.ExecutionContext.Provider.CreateParameter();
　newParameter.DbType = paramType;
　newParameter.Direction = paramDirection;
　newParameter.ParameterName = paramName;
　if (paramDirection == ParameterDirection.Input ||
　　paramDirection == ParameterDirection.InputOutput)
　{
　　newParameter.Value = base.TestContext.DataRow[dataColumnName];
　}
　return newParameter;
}

正如在图 9 中所看到的，测试方法配备了一个属性，它通知测试工具：希望针对从 DecisionAllocationTestData 表（位于本地 SQL Server Express 实例上的 TestDB_DataDriven 数据库中）检索到的每行数据调用一次。DatabaseTestAction 类代表测试中的一个操作，该测试包含要执行的测试脚本和评估结果的测试条件。您会注意到我创建了五个 DbParameter 实例，代表在测试脚本中引用的变量；请特别注意，这些参数有的是输出参数。CreateParameter 方法只是个小型帮助程序方法，用于创建实例并有选择地使用测试上下文中的数据填充实例。

您接下来看到的测试脚本定义为引用 DbParameter 实例，我将这些实例做为 Execute 方法的参数。如果您熟悉 ADO.NET 代码，您将看到这就是参数化的 SQL。

接着，我调用默认 TestService 实例的 Execute 方法，将 DbParameter 实例做为参数传递。执行后我会验证结果。验证时只需从 DataRow 检索预期值，然后将其与输出参数进行比较即可。

图 9 中的示例显示，可以不使用设计器，直接将数据库单元测试 API 设为目标。我使用从测试表中检索到的数据推动存储过程的执行；所测试的存储过程使用前三个输入值计算共享的数量，这些共享从不同位置检索以执行客户的决策。此计算仅取决于输入，过程很复杂，但输出很简单。因此，最好使用数据驱动格式编写此测试，而不是多次重复相同的测试，每次只是数据不同。

至此，我已阐述了几种不同的方法，供您修改或使用现有 API，从而充分利用事务或创建数据驱动的测试。可以使用几种方法扩展或修改数据库单元测试 API，例如添加更多的测试条件或创建自己的测试服务。因此，下面我们就来看看扩展框架的方式。

自定义测试条件

数据库单元测试功能附带六个测试条件，它们可用于验证单元测试的执行。尽管这些测试条件足以应对基本应用情况，很多用户还是很快发现他们需要验证的是一个结果集，而非单个值，因此我另行构建了两个测试条件。在 Team System 数据团队发布的一组 Visual Studio 2008 Power Tools 中，这两个测试条件和 LoggingTestService 是新增的内容。要下载这些功能强大的新工具，请参阅 go.microsoft.com/fwlink/?Linkid=107300。

第一个测试条件是 ChecksumCondition。在设计时，它生成预期结果的哈希。在执行时，实际的结果被混列并将结果值与预期结果相比较。其次是 ExpectedSchemaCondition，用于在设计时收集和存储预期的架构。在执行时，实际架构与预期架构相比较。

利用测试条件时，用户可创建数据库单元测试类并从可用条件列表中添加测试条件（将新测试类添加到项目时会自动添加对包含新条件的程序集的引用）。

用户可通过按配置属性中的椭圆访问测试条件的配置。结果对话框（如图 10 所示）允许用户指定并执行检索预期数据的查询；在此图中，显示的数据是由 DBPro Data 生成器生成的随机（无意义）数据。第一次显示时，测试中的 T-SQL 在文本框中提供。用户可随后修改测试代码以反映其实际想要的查询，然后单击“Retrieve”（检索）按钮根据服务器执行代码并显示结果。用户对结果感到满意后，便可单击“OK”（确定），测试条件会相应对自身进行配置。

图 10共享的测试条件配置

用户不必再与条件进行交互。对最终结果有所了解后，您可创建这些测试条件。开发先前的测试条件时，所关注代码的主体在设计时行为中。在下一章节中我将介绍要点；完整的代码位于 msdn.microsoft.com/msdnmag/code08.aspx。

定义测试条件

定义新的测试条件时，我发现最简单的方法是先定义条件的框架和注册，在开发实际的条件逻辑前，先验证框架是否正常工作。由于两种示例测试条件极为相似，我定义了一个通用基础类，如图 11 中所示。项目编译完毕后，我接着定义了注册 XML 文件，称为 UnitTesting.Samples.extensions.xml，如图 12 中所示。

Figure12UnitTesting.Samples.extensions.xml

<?xml version="1.0" encoding="utf-8"?>
<extensions
　assembly="UnitTesting.Samples, Version=1.0.0.0,
　　Culture=neutral, PublicKeyToken=382814fd17d42dea" version="1"
　xmlns="urn:Microsoft.VisualStudio.TeamSystem.Data.Extensions"
　xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
　xsi:schemaLocation="urn:Microsoft.VisualStudio.TeamSystem
　　.Data.Extensions
　　Microsoft.VisualStudio.TeamSystem.Data.Extensions.xsd">
　<extension
　　type="UnitTesting.Samples.TestConditions.ExpectedSchemaCondition"
　　enabled="true"/>
　<extension type=" UnitTesting.Samples.TestConditions.ChecksumCondition"
　　enabled="true"/>
</extensions>

Figure11定义的常用基础类

namespace UnitTesting.Samples.TestConditions
{
　public abstract class DataSetTestCondition : TestCondition
　{
　　//...
　}
}
namespace UnitTesting.Samples.TestConditions
{
　[DisplayName("Checksum")]
　public class ChecksumCondition : DataSetTestCondition
　{
　　// ...
　}
}
namespace UnitTesting.Samples.TestConditions
{
　[DisplayName("Expected schema" )]
　public class ExpectedSchemaCondition : DataSetTestCondition
　{
　　// ...
　}
}

我想将扩展文件直接添加到项目中，并将其设置为自动复制到输出目录，这样便于在开发和部署期间引用和使用。最后一步是设置自动部署，方法是将扩展文件复制到 DBPro 目录中，并将测试条件程序集安装到全局程序集缓存 (GAC) 中。通过生成后步骤或使用提升权限运行命令提示可达此目的。在我这个项目的生成后步骤中，我使用了以下脚本：

set TargetNameVar=$(TargetName)
set DevEnvDirVar=$(DevEnvDir)
set WindowsSDKVar=$(ProgramFiles)Microsoft SDKsWindowsV6.0A
copy /Y %TargetNameVar%.extensions.xml "%DevEnvDirVar%....DBPro*"
copy /Y %TargetNameVar%.pdb "%DevEnvDirVar%PublicAssemblies*"
"%WindowsSDKVar%Bingacutil" /if %TargetNameVar%.dll

如果想要将脚本作为单独的 .bat 文件运行，可修改前三行以从环境变量（而不是 MSBuild 变量）中检索值。

这一初始设置完成后，在测试条件下拉列表中您可看到两个新条件。我将 DisplayNameAttribute (msdn2.microsoft.com/system.componentmodel.displaynameattribute) 添加到了测试条件中，以便它们显示为 Checksum 和 Expectedschema。既然设置已完成，我便需要开发出测试条件的设计时体验，以便用户可以单击属性浏览器中的椭圆并配置条件实例。

如果您已在 Visual Studio 中设计过 Windows 窗体的组件，可能已经很熟悉 .NET Framework 中的 UITypeEditor。UITypeEditor (msdn2.microsoft.com/system.drawing.design.uitypeeditor) 和 EditorAttribute (msdn2.microsoft.com/system.componentmodel.editorattribute) 使组件开发人员可以设计自定义的编辑体验，并将其指配给（通过 EditorAttribute）在 IDE 中设计的组件属性。在本例中，我想塑造模式对话框这种体验，所以我按图 13 中所示定义了编辑器。因为两种测试条件的配置方式相同，所以我在基础类上定义属性：

Figure13定义编辑器样式

namespace UnitTesting.Samples.TestConditions.Design
{
　class DataSetEditor : UITypeEditor
　{
　　public override UITypeEditorEditStyle
　　　GetEditStyle(ITypeDescriptorContext context)
　　{
　　　return UITypeEditorEditStyle.Modal;
　　}
　　
　　public override object EditValue(
　　　ITypeDescriptorContext context,
　　　IServiceProvider provider, object value)
　　{
　　　MessageBox.Show("DataSetEditor::EditValue");
　　　return value;
　　}
　}
}[DesignOnly(true)]
[Editor(
　typeof(UnitTesting.Samples.TestConditions.Design.DataSetEditor),
　typeof(System.Drawing.Design.UITypeEditor))]
public string Configuration
{
　　get { return "Press to configure"; }
　　set { }
}

在编译和部署测试条件时，我看到了“配置”属性，单击椭圆后会显示消息框。至此，已完成了所有需要与 Visual Studio 集成的代码，我可以集中精力处理测试条件本身的逻辑了。

首先我创建了一个窗体，它将通过刚建立的 DataSetEditor 显示出来，允许用户配置测试条件预期的数据集。此窗体（名为 DataSetSelectorDialog）以测试中的 T-SQL 为种子，并允许用户根据目标服务器执行 T-SQL，以在配置测试数据前预览数据。一旦用户对数据集感到满意，便可以单击对话框中的“OK”（确定），这表示测试条件应使用数据集并将控件返回编辑器。

接下来，我会修改编辑器，使其在用户单击“OK”（确定）后显示并处理窗体内容。通常，UI 编辑器返回应在所编辑属性中存储的值，但在本例中，我想要属性显示 "Press here to configure" 文本并将数据集返回给已编辑的测试条件。由于条件处理数据集的方式各不相同，我在基础类上定义了一种虚拟方法，让编辑器调用这个方法设置数据集实例，派生类会覆盖方法以添加其特定的实现。有了这些更改，EditValue 方法现在如图 14 中所示。在此，我检索 IUIService 以显示模式对话框；此服务将模式对话框的显示与 Visual Studio 窗口操作行为的其余部分集成。

Figure14EditValue 方法

public override object EditValue(
ITypeDescriptorContext context, IServiceProvider provider, object value)
{
　IUIService uiService = (IUIService)provider
　　.GetService(typeof(IUIService));
　DataSetTestCondition cond = context.Instance as DataSetTestCondition;
　if (uiService != null && cond != null)
　{
　　DataSetSelectorDialog dsDialog = new DataSetSelectorDialog();
　　if (cond.Site != null)
　　{
　　　dsDialog.Text = string.Format(CultureInfo.CurrentCulture,
　　　　"Configuration for {0}", cond.Site.Name);
　　}
　　dsDialog.Query = cond.GetTestScript();
　　dsDialog.StartPosition = FormStartPosition.CenterParent;
　　if (uiService.ShowDialog(dsDialog) == DialogResult.OK)
　　{
　　　value = dsDialog.Query;
　　　if (cond != null)
　　　{
　　　　cond.ConfigureExpectedDataSet(dsDialog.Result);
　　　}
　　}
　}
　return value;
}

既然您已看到了测试条件的设计时行为，就让我们了解一下根据目标服务器执行测试脚本并将其结果收集到数据集时发生的情况。测试执行完毕后，创建 ExecutionResult 类的一个实例并用测试执行的相关信息（包括数据集）进行填充。测试工具随后遍历为验证执行结果而配置的所有测试条件，并调用每个测试条件的 Assert 方法来验证这些结果。在本例所示的测试条件中，它们检索结果数组中第一个 ExpectedResult 中的数据集，然后 ChecksumCondition 生成实际数据集的哈希并将其与设计过程中生成的哈希相比较。ExpectedSchemaCondition 反序列化代表预期数据表（及其列）的空数据集并将其与测试生成的数据集相比较。

修改测试执行

通过 DatabaseTestService 类（在 DatabaseTestClass 的静态 TestService 属性上注册）的实例访问连接字符串、数据库部署和测试执行的默认行为。DatabaseTestService 类的方法标记为虚拟，因此可以单独或全部覆盖这些方法以更改测试的执行方式。有时您可能想要修改默认行为，例如，您在使用自定义连接字符串加密/解密机制、修改部署数据库或生成数据的方式，或自动记录执行结果。

通过编写自己的测试服务类，然后用工具注册该测试服务以便其可在测试执行期间使用，这样就能实现每个（或多个）此类修改。在本例中，我将编写一个测试服务，它会使用数据集序列化在文件中记录测试执行结果。此服务可配置为记录零个结果、记录所有结果或仅记录失败的结果。这一简单的服务使在工具中查看测试执行的结果变得非常便捷。

首先定义类；我只需修改测试执行的方式，因此类如图 15 中所示。正如您所看到的，LoggingTestService 是 DatabaseTestService 类的子类，并覆盖 Execute 方法。接着需要添加结果记录。注意，Execute 的默认实现是执行测试脚本并评估测试条件；但这与我的需求不符，因为如果验证失败，我将不能访问执行结果。因此，为了达到我的目标，我将在调用基础 Execute 方法后评估分配的测试条件，然后相应记录结果。完成的 Execute 实现如图 16 中所示。

Figure16执行实现

public override ExecutionResult[] Execute(
　ConnectionContext scriptExecutionContext,
　ConnectionContext privilegedExecutionContext,
　DatabaseTestAction action,
　params System.Data.Common.DbParameter[] sqlParameters)
{
　// We want to evaluate the conditions ourselves so that we
　// can log the results from every test's execution
　List<TestCondition> conditions = new List<TestCondition>();
　if (action != null)
　{
　　conditions.AddRange(action.Conditions);
　　action.Conditions.Clear();
　}
　// Execute the test
　ExecutionResult[] results = base.Execute(
　　scriptExecutionContext,
　　privilegedExecutionContext,
　　action,
　　sqlParameters);
　// Verify and log the results
　bool verificationFailed = false;
　try
　{
　　foreach (TestCondition condition in conditions)
　　{
　　　if (condition.Enabled)
　　　{
　　　　condition.Assert(privilegedExecutionContext.Connection, results);
　　　}
　　}
　}
　catch
　{
　　verificationFailed = true;
　　throw;
　}
　finally
　{
　　if (results != null &&
　　　(Verbosity == LogVerbosity.AllResults ||
　　　(verificationFailed && Verbosity == LogVerbosity.OnlyFailure)))
　　{
　　　// Serialize the dataset to an .xml file to be visualized
　　　string resultPrefix = Guid.NewGuid().ToString("N");
　　　for (int resultIndex = 0; resultIndex < results.Length;
　　　　resultIndex++)
　　　{
　　　　string dsFilePath = Path.GetFullPath(string.Format(
　　　　　CultureInfo.CurrentCulture,
　　　　　"{0}-{1}.xml", resultPrefix, resultIndex));
　　　　ExecutionResult result = results[resultIndex];
　　　　result.DataSet.WriteXml(dsFilePath,
　　　　　System.Data.XmlWriteMode.IgnoreSchema);
　　　　Trace.TraceInformation("Log {0} {1}", resultIndex, dsFilePath);
　　　}
　　}
　}
　return results;
}

Figure15LoggingTestService 类

namespace UnitTesting.Samples
{
　public class LoggingTestService : DatabaseTestService
　{
　　public override ExecutionResult[] Execute(
　　　ConnectionContext scriptExecutionContext,
　　　ConnectionContext privilegedExecutionContext,
　　　DatabaseTestAction action,
　　　params System.Data.Common.DbParameter[] sqlParameters)
　　{
　　　// Execute the test
　　　ExecutionResult[] results = base.Execute(
　　　　scriptExecutionContext,
　　　　privilegedExecutionContext,
　　　　action,
　　　　sqlParameters);
　　　return results;
　　}
　}
}

它仍使用基础 Execute 实现，但随后它使用操作的测试条件验证结果并将该执行的结果写入文件。我使用 GUID 生成一个独有的名称，因为这个方法在单一测试执行期间会被多次调用。另外，检查空结果也很重要，因为调用无操作的 Execute 很常见。

服务编译为程序集后，我仍需要进行注册以便能在测试执行过程中使用。在我的这个示例中，我要向程序集中的所有测试注册服务，但仅在测试失败时做记录，所以我将 IntializeAssembly 方法修改为如下所示：

[AssemblyInitialize()]
public static void IntializeAssembly(TestContext ctx)
{
　LoggingTestService testService = new LoggingTestService();
　testService.Verbosity = LoggingTestService.LogVerbosity.OnlyFailure;
　DatabaseTestClass.TestService = testService;
　// Setup the test database based on setting in the
　// configuration file
　DatabaseTestClass.TestService.DeployDatabaseProject();
　DatabaseTestClass.TestService.GenerateData();
}

现在，如果我运行的单元测试失败，日志文件的路径会输出到测试的运行目录并且文件路径将显示在该测试的结果窗口中。

为查看造成测试失败的结果，我创建了一个非常简单的 Windows 窗体应用程序（在附带的示例代码下载中），用于反序列化和显示数据集。结束前，我应提到 Visual Studio 测试工具在其自身的 AppDomain 中执行每个测试程序集。由于服务实例是通过静态属性注册的，所以服务注册的持续时间仅限 AppDomain 的生存期。这意味着您需要在每个测试程序集的初始化期间注册测试服务。另外，您还应看一下侧栏“Team System for Database Professionals：资源”，了解更改数据库架构的详细信息。

展望

我在本文中提及了 DBPro 的诸多功能，但掌握精髓的最佳途径是亲手实践。我建议您亲身体验产品，包括使用数据生成 API 和新的 Visual Studio 2008 PowerTools。如果您遇到任何问题或有任何疑问，请随时访问我们的论坛，网址为：forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=725&SiteID=1。此外，另请访问 Sachin Rekhi 的白皮书“使用 Team Edition for Database Professionals 的数据库单元测试”，网址为msdn2.microsoft.com/bb381703。