科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道基础软件使用VSTS进行单元测试并生成用于Unit Test Framework的源代码(1)

使用VSTS进行单元测试并生成用于Unit Test Framework的源代码(1)

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

Scott 详细介绍自动化单元测试的基本内容,以及由 Microsoft Visual Studio 2005 Team System 提供的 Unit Test Framework 中包含的代码生成引擎。

作者:佚名 来源:CSDN  2007年8月31日

关键字: VSTS 单元 测试

  • 评论
  • 分享微博
  • 分享邮件

简介

随着业务的革新和发展,运行它们的系统也需要进行更新。随业务的发展、革新以及与合作伙伴、客户和供应商的结合,这些系统将在复杂性方面持续扩增。

这种复杂性迫使 IT 的领导者们在开发过程中(即,在实现之前)确保质量。有一种方法可使开发人员减少进入 QA 环节的故障数量,即,针对自定义代码严格执行自动化单元测试。在开发过程中强制使用自动化单元测试可为团队成员提供有关如何使用自定义代码的示例(这些示例易于使用并自行记录)。

使用结构化、自动化单元测试面临的挑战之一是完成这些任务所需的代码总数。(测试代码需要使用大量代码!)代码生成的概念(简单定义为“创建软件的软件”)正随着时间的快速推移而逐渐深入到团队 IT 开发之中。有些人认为代码生成有助于缩短“推向市场”策略的时间,强制内部标准/协定,并促进开发过程。

Microsoft 认识到这一需要后提供了一个功能丰富、带有下一代开发平台 Visual Studio 2005 Team System (VSTS) 的代码生成引擎。本文提供针对单元测试代码生成的循序渐进的指导,并深入探讨如何在用例中使用。

重新思考单元测试

请考虑以下情况:您负责为公司生成下一代系统,同时您是较大的开发团队中的一员。您是 UI 开发人员,负责尽可能多地创建 Microsoft ASP.NET/Microsoft WinForms。您依赖“中间层”团队完成其中间层组件 — 这些组件用于执行数据库 CRUD (Create-Retrieve-Update-Delete) 以及与该系统中每个实体相关的业务规则。

经过几周的 UI 开发,您完成了窗体并且收到了中间层开发人员打算向您提交其类库的消息。表 1 提供一段对话示例,说明我们大多数人在开发过程中都会遇到的一些事情。

表 1. UI 开发人员和中间层开发人员间的示例对话

中间层:

“这些对象随时供您使用 — 为此,只需获取 OurSystemBL.dll 的最新版本。”

UI:

“谢谢。您有供我们查看文档吗?”

中间层:

“哈哈!是的,当然有!我们花了很多时间编写它!请查看 Design Document — 噢,请等一等,它还没有完成……(不久之后即可完成!)” 

UI:

“您使用 XML 文档了吗?”

中间层:

“在构造函数中,但许多方法都不使用。” 

UI:

“显示如何创建、执行并删除对象的示例代码,怎么样?” 

中间层:

“我已经附加了一个示例 WinForms 应用程序(从我的工作区),它应该能够提供一些您所需的内容……,虽然它不在 Microsoft Visual SourceSafe 中。”

在考虑如何进行这样有趣的 项目之后,您打定了主意,决定检验中间层的单元测试套件。在深入钻研该代码之后,您注意到该窗体有两个未标记的文本框,以及三个标记为 button1、button2 和 button3 的按钮(幸运的话,它们将排列在窗体上)。接下来,在查看与这些按钮相关的事件之后,您认识到这些代码都未经注释,并且数据变量都被命名为 x、y、z。如果幸运,您还会注意到 button1 和 button2 执行该对象的 Save() 方法,而 button3 执行 Delete() 方法。执行时,您会接收到很多 System.Exception 错误,这是因为遗漏了很多配置设置。

这显然是一个特例,我希望多数开发团队不要进行这一试验,下面让我们看一下该方案中“单元测试”遇到的问题:

这种形式的单元测试代码不是结构化的:代码充斥到按钮单击事件中并且难以编译。



这种形式的单元测试代码记录得不太好。



这种形式的单元测试并不基于“已知”为好或坏的数据 — 它完全依赖于输入到那些未标记的文本框的内容。

单元测试代码不能自动重复,它基于输入的代码。



单元测试代码覆盖是未知的 — 用数据指示实际测试的代码量。 



实现的详细信息不易于在团队成员间进行传播。 

输入自动化单元测试

xUnit 框架在 1998 年作为 eXtreme 编程的核心概念引入。它提出了一个有效的机制,有助于开发人员将结构化、有效且自动的单元测试添加常规开发活动中。从那以后,该框架演化为针对自动化单元测试框架的实际标准。

创建自动化单元测试的用例

简单说,自动化单元测试是:

结构化的。 

自行记录的。

自动且可重复的。 

基于已知数据。 

旨在测试积极和消极操作。

非常适合跨不同计算机的测试实现。

配置、实现和执行的示例。

xUnit 框架元素

表 2 分析 xUnit 框架以及对应于 Visual Studio 2005 Team System 的 Unit Testing Framework 等价物的基本概念。

表 2. 相应的 xUnit 框架和 VSTS Unit Testing Framework 概念

xUnit 框架概念 VS 2005 等价物(参见下面的属性) 描述

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章