模板
教程
环境
性能
功能
管理
使用 Visual Studio 2005 Team System 进行单元测试
使用 Visual Studio 2005 Team System 进行单元测试 单元测试工具
随着业务的革新和发展，运行它们的系统也需要进行更新。随业务的发展、革新以及与合作伙伴、客户和供应商的结合，这些系统将在复杂性方面持续扩增。
这种复杂性迫使 IT 的领导者们在开发过程中(即，在实现之前)确保质量。有一种方法可使开发人员减少进入 QA 环节的故障数量，即，针对自定义代码严格执行自动化单元测试。在开发过程中强制使用自动化单元测试可为团队成员提供有关如何使用自定义代码的示例(这些示例易于使用并自行记录)。
使用结构化、自动化单元测试面临的挑战之一是完成这些任务所需的代码总数。(测试代码需要使用大量代码!)代码生成的概念(简单定义为“创建软件的软件”)正随着时间的快速推移而逐渐深入到团队 IT 开发之中。有些人认为代码生成有助于缩短“推向市场”策略的时间，强制内部标准/协定，并促进开发过程。
Microsoft 认识到这一需要后提供了一个功能丰富、带有下一代开发平台 Visual Studio 2005 Team System (VSTS) 的代码生成引擎。本文提供针对单元测试代码生成的循序渐进的指导，并深入探讨如何在用例中使用。
重新思考单元测试
请考虑以下情况：您负责为公司生成下一代系统，同时您是较大的开发团队中的一员。您是 UI 开发人员，负责尽可能多地创建 Microsoft ASP.NET/Microsoft WinForms。您依赖“中间层”团队完成其中间层组件 — 这些组件用于执行数据库 CRUD (Create-Retrieve-Update-Delete) 以及与该系统中每个实体相关的业务规则。
经过几周的 UI 开发，您完成了窗体并且收到了中间层开发人员打算向您提交其类库的消息。下面提供一段对话示例，说明我们大多数人在开发过程中都会遇到的一些事情。
| UI 开发人员和中间层开发人员间的示例对话 | |
|
中间层： |
“这些对象随时供您使用 — 为此，只需获取 OurSystemBL.dll 的最新版本。” |
|
UI： |
“谢谢。您有供我们查看文档吗？” |
|
中间层： |
“哈哈！是的，当然有！我们花了很多时间编写它！请查看 Design Document — 噢，请等一等，它还没有完成……（不久之后即可完成！）” |
|
UI： |
“您使用 XML 文档了吗？” |
|
中间层： |
“在构造函数中，但许多方法都不使用。” |
|
UI： |
“显示如何创建、执行并删除对象的示例代码，怎么样？” |
|
中间层： |
“我已经附加了一个示例 WinForms 应用程序（从我的javascript:tagshow(event, '%B9%A4%D7%F7');" href="javascript:;" target=_self>工作区），它应该能够提供一些您所需的内容……，虽然它不在 Microsoft Visual SourceSafe 中。” |
在考虑如何进行这样有趣的项目之后，您打定了主意，决定检验中间层的单元测试套件。在深入钻研该代码之后，您注意到该窗体有两个未标记的文本框，以及三个标记为button1、button2和button3的按钮(幸运的话，它们将排列在窗体上)。接下来，在查看与这些按钮相关的事件之后，您认识到这些代码都未经注释，并且数据变量都被命名为 x、y、z。如果幸运，您还会注意到button1和button2执行该对象的Save()方法，而button3执行Delete()方法。执行时，您会接收到很多 System.Exception 错误，这是因为遗漏了很多配置设置。
这显然是一个特例，我希望多数开发团队不要进行这一试验，下面让我们看一下该方案中“单元测试”遇到的问题：
| • |
这种形式的单元测试代码不是结构化的：代码充斥到按钮单击事件中并且难以编译。 | ||||
| • |
这种形式的单元测试代码记录得不太好。 | ||||
| • |
这种形式的单元测试并不基于“已知”为好或坏的数据 — 它完全依赖于输入到那些未标记的文本框的内容。
| ||||
| • |
实现的详细信息不易于在团队成员间进行传播。
|
