JBuilder 2005单元测试之慨述

  一个产品只有通过检验才能投放市场,同样的,一个业务类也只有在经验测试后才能保证功能的正确性,以便被其他类或程序调用,否则隐藏其中的Bug就蔓延开了。业务功能点测试是测试人员的职责,但业务类API的正确性必须由开发人员保证。

  回忆一下最近你所开发的系统,往往一个最难忘的情节是通宵达旦地毯式搜索某个刁专的Bug,历尽千辛万苦,最终找到并解决了它。查找一个隐藏的Bug往往是踏破铁蹄无觅处,而找到后却是:解决全不费功夫。

  造成这尴尬窘局有以下几点原因:

  其一是使用增量式测试策略,即先编写功能代码,在模块开发完毕后才回过头来编写测试用例,因为一个功能模块可能包含许多相互关联的类,形成了层层调用,交错复杂的调用网络,一旦发现了Bug,只得查户口似的逐一排查,其艰辛程度可想而知。

  其二是使用不正确的测试方法,如在每个类中提供一个main()测试函数,对类中的功能方法进行测试,通过运行类的main()方法查看类功能的正确性。在某种程序上,这或许是一个值得赞扬的工作习惯,但工作方式却不足取。因为每个类都必须单独运行,以执行其测试功能,并由开发人员观察测试的正确性。随着程序规模的扩大,类数目直线上升,原有的类也会发生代码的调整,一些功能点可能就变成了漏网之鱼,变成了茫茫"类"海里的黑户口,将来"违法乱纪"起来就很难监控了。

  针对这些传统测试思想的不足,测试先行、频繁测试、自动测试的测试思想被越来越多的开发人员所接受并付诸实践。

  测试先行乍听起来有点让人不可思议,一件东西还没有做出来就想着怎么去测试它?仔细分析,这并不荒唐,因为这让你在设计类时,站在调用者的角度去理解类的对外接口,迫使你深入理解类的外在关系,考虑接口的用途,而在具体编写程序时才去具体考虑内部实现细节,这样设计出接口将更易使用,结构也会更趋合理。

  频繁测试,即指测试不应当是阶段性的工作,而应当在程序编写过程中不断进行。因为系统中的类之间往往都存在较多的关联关系,当更改了类的功能时,往往会有多个类受到直接或间接的影响。所以你应该频繁测试以及早发现这种因功能、调整而引起的Bug,越早发现错误解决它的代价越小。频繁测试也是XP编程的一个重要环节,XP编程总让人觉得他们注重功能实现而忽视测试,其实他们也非常关注测试,毕竟测试可以使他们尽可能快的稳步前进。

  所谓自动测试并不是说有一个工具可以让你像安检器一样,自动测试出你类中的问题。而是指应用一定的测试框架,为每个业务类编写独立的测试用例,类代码调整后,对应的测试用例同步调整。多个测试用例组成一个测试套件一起批量运行,它们就像一个强大的Bug嗅探器,一旦发现Bug就会输出特定的信息报告错误,只要一个测试用例没有通过测试就说明程序中有问题。测试用例中所包含的测试规则完成由你定制,这个测试套件对Bug嗅探的"灵敏度"完全取决于测试用例的测试规则,框架提供编写和运行测试用例的规范性方法。

  在编写一个业务类时,需要相应编写对应的测试用例,一开始挺招"惯性定律"抵触的,因为它要求你将创建一个测试用例类,似乎需要更多的工作。但你的付出是会得到加倍回报的,随着软件类规模的增大你会发现,当传统测试方法越来越捉襟见肘,穷于应付时,基于测试框架的测试技术依然"谈笑自如"。当然别人这么说,我们也不应当马上就深信不疑,疑惑永远是值得推崇的科学精神,我们应该通过自己的实践却真真切切地体会这种改进所带来的快乐。

(0)

相关推荐

  • JBuilder 2005单元测试之慨述

    一个产品只有通过检验才能投放市场,同样的,一个业务类也只有在经验测试后才能保证功能的正确性,以便被其他类或程序调用,否则隐藏其中的Bug就蔓延开了.业务功能点测试是测试人员的职责,但业务类API的正确性必须由开发人员保证. 回忆一下最近你所开发的系统,往往一个最难忘的情节是通宵达旦地毯式搜索某个刁专的Bug,历尽千辛万苦,最终找到并解决了它.查找一个隐藏的Bug往往是踏破铁蹄无觅处,而找到后却是:解决全不费功夫. 造成这尴尬窘局有以下几点原因: 其一是使用增量式测试策略,即先编写功能代码,在模块

  • Python Django框架单元测试之文件上传测试示例

    本文实例讲述了Python Django框架单元测试之文件上传测试.分享给大家供大家参考,具体如下: Submitting files is a special case. To POST a file, you need only provide the file field name as a key, and a file handle to the file you wish to upload as a value. For example: >>> c = Client()

  • Oracle PL/SQL入门慨述

    正在看的ORACLE教程是:Oracle PL/SQL入门慨述.一.PL/SQL出现的目的 结构化查询语言(Structured Query Language,简称SQL)是用来访问关系型数据库一种通用语言,它属于第四代语言(4GL),其执行特点是非过程化,即不用指明执行的具体方法和途径,而是简单的调用相应语句来直接取得结果即可.显然,这种不关注任何实现细节的语言对于开发者来说有着极大的便利. 然而,对于有些复杂的业务流程又要求相应的程序来描述,那么4GL就有些无能为力了.PL/SQL的出现正是

  • JS异步代码单元测试之神奇的Promise

    前言 写这篇文章的起因是在写单元测试时,做形如下测试时 new Promise((resolve, reject) => reject(1)).then().catch(err => { console.log(err) }) async function jestTest () { await Promise.resolve().then() console.log('这个时候catch预期已经被调用,且输出日志') } jestTest() 无法使用await将测试代码恰好阻塞到catch

  • python单元测试之pytest的使用

    一.前提准备 1.前提:需要安装pytest和pytest-html(生成html测试报告) pip install pytest 和 pip install pytest-html 安装插件:pip install 插件名 2.命名规范 Pytest单元测试中的类名和方法名必须是以test开头,执行中只能找到test开头的类和方法,比unittest更加严谨 Pytest: setup, setup_class 和 teardown, teardown_class 函数 ( 和 unittes

  • 详解Java单元测试之Junit框架使用教程

    目录 单元测试 Junit单元测试框架 单元测试快速入门 单元测试 单元测试就是针对最小的功能单元编写测试代码,Java程序最小的功能单元是方法,因此,单元测试就是针对Java方法的测试,进而检查方法的正确性 目前测试方法是怎么进行的,存在什么问题? 1.只有一个main方法,如果一个方法的测试失败了,其他方法测试会受到影响 2.无法得到测试的结果报告,需要程序员自己去观察测试是否成功 3.无法实现自动化测试 Junit单元测试框架 1.Junit是使用Java语言实现的单元测试框架,它是开源的

  • 前端单元测试之UI测试功能性代码测试教程

    目录 前言 UI测试: 功能性代码测试: 让人闻风丧胆的单元测试 代码测试代码 Jest介绍 一.基础教程 安装 源码开发 测试用例编写 开始测试 二.核心API 全局方法 匹配器 异步代码测试 回调 Promise Async/Await Mock Functions 使用 mock 函数 .mock 属性 Mock 的返回值 Mocking Modules 快照测试 前言 <孤勇者>最近火爆的一塌糊涂,占领了小学生.甚至幼儿园,连我家2岁多的儿子尽然也会哼几句.虽然他以为这首歌是奥特曼的主

  • JBuilder2005单元测试之JUnit框架

    简单的框架 JUnit是由Erich Gamma和Kent Beck开发的开源测试框架,JBuilder集成了这个框架并对此做了扩展.JUnit之所以流行并为广大的开发人员所推崇,一是因为它实战性强,功能强大,二是因为它实在简单.一个产品或框架要能有生命力,最好都具备这样的特点. 简单地讲这个框架提供了许多断言(assert)方法,允许你设置测试的规则,如:assertEquals().assertNull().assertNotSame().assertTrue()等方法,一个测试用例包括了多

  • JBuilder2005单元测试之捆绑多个用例

    目前我们只为Subsection类生成了一个测试用例,在这节里,我们按照前述的方法,通过Test Case向导为StringUtils类创建一个测试用例代码框架,并编写测试方法,然后将这两个测试用例捆绑组合在一个测试套件中一起运行. 选中StringUtils类,通过File->New..->Test,双击Test Case图标为StringUtils类的string2Array()方法创建测试用例,接受默认的测试用例类名TestStringUtils. 在向导生成的测试用例代码框架中,删除测

  • JBuilder2005单元测试之创建测试固件

    在测试用例中通过setUp().tearDown()创建测试固件,只能使这个测试固件在单个测试用例的不同测试方法中共用,如果有多个测试用例都需要使用相同的测试固件,就需要将测试固件抽取到一个独立的类中.JBuilder提供了3个预定义的测试固件类,它们分别是: ·JDBC测试固件(JDBC Fixture):用于获取数据库连接的测试固件,用户仅需要通过设置一些数据库信息,就可以用方便的方法获取数据连接. ·JNDI 测试固件(JNDI Fixture):用于模拟从JDNI环境中获取对象的测试固件

随机推荐