分享
 
 
 

为 PL/SQL 构建代码分析实用工具(三)

王朝mssql·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

第二部分:从测试开始

在编写代码前建立一个测试计划,可以节省您的时间。

在本系列的 第一篇文章 中,我决定构建一个可以对代码进行质量检查的实用工具:非凡是识别 PL/SQL 程序包中具有歧义或者潜在歧义的超载问题。

此外,我还识别数据源( ALL_ARGUMENTS 数据字典视图)和代码( DBMS_DESCRIBE 程序包),以帮助构建实用工具。下一步要做什么呢?

坦率地说,我自然倾向于打开我所喜爱的集成开发环境 (IDE) 并开始动指如飞地编写代码,投入激动人心的创作之中。我希望在工作时思考并得出结论,不断地应对挑战,使工作成果运行起来,然后对其进行微调。

这种方法有积极的方面(您当然不会有过度设计的风险),但也有很多缺点。首先,假如我所使用的构建方法是直通式构造非线性系统 — 常被亲切地称为 HRCLS 或 Hercules (一种 非常 轻型的方法论),我最终不会仅是微调代码。绝对不会,在我将范围缩小到最终目的、目标和实质内容时,我最终将会以重写整个程序 — 一次、两次或三次。但是,尽管可以激动地看到,经过自己的努力,实用工具成形、进步并改观,但这会浪费很多的时间。

对于 Codecheck ,我会忍住最初的诱惑。我不会在项目开始的头 60 秒内就编写代码,而是做一个简单的声明:我保证使我编写的代码适用于一个全面的测试计划。

这与避免 Hercules 综合症有什么必然的关系呢?让我们来考虑这种保证的含义:

我将制订一个测试计划,它非常全面,精心策划了数十个(甚至可能有 100 个之多)测试方案,包括参数的数量、各种数据类型的结合以及缺省值的有无。

我要设计、构建和运行测试,这些测试可确定我的代码是否满足测试计划的要求:换言之,设计、构建和运行涵盖我的全部测试方案的测试。

天哪,这听起来确实很有道理,不是吗?我的意思是,谁 会 一直做所有的这些事情?况且,我们都知道这样的事实:我们之中很少有人实际上会花时间,或在手边有必备的工具去做全面的测试。实际上我认为,世界上至少百分之九十的软件开发人员和开发团队(包括我自己)远远不会完全按上述保证去做。

对我来说,在开发初始时我表明要执着地进行测试,我发现这一点促使我实现了 Codecheck 。

定义范围,做出假设

在开发一项测试策略并构造测试之前,我需要确定项目的使用范围。用户群通常确定(并经常更改)项目的使用范围。对于 Codecheck 以及我制作的很多其他实用工具,您,开发人员,是我的用户,但我仍然需要确定使用范围,把您的需求作为我的指导。我的目标是产生一个代码体,能立即帮助开发人员提高代码质量,但也可以作为一项稳定而且可扩展的功能,开发人员可以将其加入代码中满足自己的需要。它必须能够处理现实世界中足够的复杂性,这样才有用处,但又不可太复杂,以至于将 Codecheck 开发变成一种全职工作。

当我深入查看 ALL_ARGUMENTS 的内容时,我吃惊地发现那些参数列表会变得非常复杂。例如,在 Oracle9 i 的环境中,一个参数可以将记录的结合数组(以前称为表的索引)作为其类型,其中记录的一个字段是另一个结合数组,以此类推。非常坦率地说,我实际上不希望必须编写代码来处理这些参数全部的可能情况。

与此相反, Codecheck 将只基于 “0 级 ” 参数来检查和进行分析:这是指在 ALL_ARGUMENTS 视图中的那些项目,当其出现在程序头时,它们对应于参数列表。实际上,这可能是您为分析超载而 所需 的全部要素,但是全部的具体资料可能在进行某种其他的代码检查时派上用场。(在撰写此文章时,我已确定了一种需要更多信息的情况:假如您将一个参数定义为表单 %ROWTYPE 的记录,则 ALL_ARGUMENTS 和 DBMS_DESCRIBE 都不会提供其类型的信息。您可能必须比较那些行类型( 1 级或更多级)的 各个字段 的数据类型以识别岐义。天哪。

定义测试策略

开发 Codecheck 的下一步是探究和定义测试策略。我曾提到过,我承诺编写能够满足测试计划的代码,这种承诺影响着开发过程。例如,我在编写如 Codecheck 等实用工具时的第一个冲动是,制作一个程序,接受一个程序包的名称并在屏幕上显示代码检查的结果。为了确定实用工具是否正确工作,我需要查看屏幕上的检查结果并对其进行分析。这听起来如何?熟悉吗?可伸缩吗?通常这种方法甚至对非常简单的程序都无效。

Codecheck 测试计划无疑会有很多测试方案,而其结果并不明确。换言之,除非我记住成功对所有这些测试方案意味着什么,否则我必须依靠手动的、直观的验证(先看这个窗口;然后将其与那个窗口的内容进行比较)。我需要用很长的时间完成一项测试(这是构成责任性的一项相当重要的要素),所以我很少进行测试 — 假如曾做过测试的话。这与我的保证相违反。

我需要找到一种更快捷方便的测试方法。使用 Java 的许多开发人员转向 Junit 。 PL/SQL 开发人员则利用 utPLSQL ,一种用于 PL/SQL 开发人员的开放源单元测试框架。(申明:我是 utPLSQL 的创建者,尽管其他人现在也帮助进行实施并制作文档。)

我不会在本文中以很大的篇幅具体描述 utPLSQL 的起源、理论基础或基本工作方式。

假如您需要了解比本文内容更具体的情况,请访问 http://utplsql.sourceforge.net/ 或 http://utplsql.oracledeveloper.nl 。

utPLSQL 简介

utPLSQL 是一种用于 PL/SQL 程序的测试框架(代码以及使用这种代码的进程的集合)。使用 utPLSQL ,您可以构造包含单元测试过程的单元测试程序包,并依照 utPLSQL 的命名规范和测试机制来设计此程序包。然后您只须简单地操作 utPLSQL 来测试程序或程序包。它运行所有测试并自动检测该测试是否成功或失败。它准确指出失败的测试方案,使您更快地确定正确的测试方案并识别应用程序中错误的原因。

这种框架是基于极限编程的单元测试概念 ( www.XProgramming.com ) 以及 Junit ( Java 单元测试框架)。下面是一些该方法进行单元测试的基本原则:

在编写代码前编写单元测试。

少做编写和更改,多做测试。

自动执行测试和生成报告:红绿灯式的方法。

图 1 表示 utPLSQL 体系结构的一个简化视图,它是以强大有效的方式自动执行测试的一个往返旅程。下面对行程中的各站作一解释:

调用 utPLSQL 测试过程执行测试程序包。 utPLSQL 按照动态 PL/SQL 和命名规范来运行任何设置代码,定位并执行单元测试程序,并进行必要的清除( “ 拆卸 ” 步骤)。

单元测试过程调用 “ 判定 API” ,它将测试结果与 “ 控制 ” 条件进行比较。

判定程序将结果(通过或失败)写到下面的结果表中。

tPLSQL 测试读出结果表中的内容,确定该测试的状态。

utPLSQL 根据结果作出报告,或者通过 DBMS_OUTPUT 送到屏幕,或者通过 UTL_FILE 送到一个文件。

让我们来看一个很简单的示例,从而大致了解单元测试程序包的内容。假设我已经创建了一个关于 SUBSTR 的封装,答应在开始和结束点之间请求一个子串(一个简单的函数)( 列表 1 )。

即使是简单的或看似不重要的程序(如 betwnStr )也需要测试 — 而实际上我必须考虑大量的测试方案(包括 NULL 开始值、 NULL 结束值以及开始大于结束等)。 列表 2 显示了测试程序包的一部分(全部测试包的内容请参见 ut_betwnstr.pkb )。关于要害部分的解释,请参见 表 1 。

也许您会想, “ 多么单调乏味!我真的必须编写所有那些代码,只是为了测试这个简单的函数吗? ” 实际上,那些在测试领域工作的人都知道,测试一个应用程序所需要编写的代码数量经常比应用程序本身更多。对于这个特定的程序包和测试代码的 utPLSQL 风格,您在某些情况下会生成全部的测试代码。实际上, ut_betwnstr 程序包 通过 对 utGen.testpkg_from_string 过程的调用而生成, 如列表 3 所示 。

即使您不生成测试程序包,也经常可以找到其他方法,利用最少的代码运行许多基于 utPLSQL 的测试 — 这正是我用 Codecheck 所做的工作。

将 utPLSQL 应用于 Codecheck

要利用 utPLSQL ,我需要构建一个单元测试程序包并调用 utAssert 程序,以确定我的代码是否通过其测试。但是,在进行这些操作之前,我需要精心制作我的测试方案。请记住:测试方案第一,其次才是代码。

现在应该寻找灵感,暂停前进,考虑一下我所提供的实用工具。我希望它能够验证什么?那些能编译但包含歧义超载的程序包的特例是什么?我能检测到什么情况?有效超载的示例是什么?究竟我需要测试正面和负面的因素。经过一段时间以后,我给出以下的内容:

有效的超载

两个超载程序带有不同数量的非缺省参数。

两个超载程序带有相同数量的非缺省参数,并在数据类型方面具有足够的差别(如 NUMBER 对 DATE )。

函数和过程具有相同名称和参数列表,包括不带参数的情况。区分这两者并没有问题,因为它们在代码中的使用方法不同。

无效的超载

两个超载程序具有不同数量的非缺省参数,导致歧义的参数列表。

两个程序具有单个参数,数据类型相同但参数名不同。

两个程序具有相同的名称,具有单个参数,但却是同系列中不同的数据类型。

一个程序没有参数,第二个程序具有一个带缺省值的参数。

一个程序具有 N 个参数,第二个程序具有 N+1 个参数,全部带有缺省值。

一个程序具有 N 个参数,其中 N-1 个参数有缺省值;第二个程序具有 N+1 个参数,其中最后两个缺省。

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有