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

本文讨论:

TDD 的优点

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

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

连接、测试条件和事务

目录

软件开发中的单元测试

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共享的测试条件配置

现在，让我们看一下如何在数据库单元测试设计器中创建、访问或修改脚本。首先从“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

修改生成的测试代码

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

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

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

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

事务

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

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

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

Figure7使用 System.Transactions

Figure6ADO.NET Transaction

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

System.Transactions

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

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

Figure8对每个测试使用事务

数据驱动的测试

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

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

Figure9提供 DbParameter 实例

正如在图 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

Figure11定义的常用基础类

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

如果想要将脚本作为单独的 .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定义编辑器样式

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

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

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

Figure14EditValue 方法

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

修改测试执行

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

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

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

Figure16执行实现

Figure15LoggingTestService 类

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

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

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

为查看造成测试失败的结果，我创建了一个非常简单的 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。