JBuilder 2005单元测试之慨述[Java编程]

一个产品只有通过查验才能投放市场,一样的,一个业务类也只有在经验测试后才能保证功效的精确性,以便被其他类或程序调用,不然躲藏此中的Bug就蔓延开了.业务功效点测试是测试人员的职责,但业务类API的精确性必须由开辟人员保证.

回想一下近来你所开辟的系统,常常一个最难忘的情节是通宵达旦地毯式搜索某个刁专的Bug,历尽千辛万苦,终究找到并办理了它.查找一个躲藏的Bug常常是踏破铁蹄无觅处,而找到后倒是:办理全不费工夫.

造成这尴尬窘局有以下几点缘由:

其一是利用增量式测试战略,即先编写功效代码,在模块开辟完毕后才回过头来编写测试用例,因为一个功效模块大概包含很多彼此关联的类,形成了层层调用,交叉复杂的调用网络,一旦发现了Bug,只得查户口似的一一排查,其艰苦程度不可思议.

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

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

测试先行乍听起来有点让人难以想象,一件东西还没有做出来就想着怎么去测试它?细心解析,这并不荒诞,因为这让你在计划类时,站在调用者的角度去理解类的对外接口,迫使你深化理解类的外在关系,考虑接口的用处,而在具体编写程序时才去具体考虑内部实现细节,这样计划出接口将更易利用,构造也会更趋公道.

频繁测试,即指测试不该当是阶段性的工作,而该当在程序编写历程中不断举行.因为系统中的类之间常常都存在较多的关联关系,当更改了类的功效时,常常会有多个类遭到直接或间接的影响.所以你应当频繁测试以赶早发现这种因功效、调整而惹起的Bug,越早发现错误办理它的代价越小.频繁测试也是XP编程的一个重要环节,XP编程总让人认为他们注重功效实现而轻忽测试,其实他们也非常关注测试,毕竟测试可以使他们尽大概快的稳步行进.

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

在编写一个业务类时,需求呼应编写对应的测试用例,一开始挺招"惯性定律"冲突的,因为它要求你将成立一个测试用例类,仿佛需求更多的工作.但你的付出是会得到加倍回报的,随着软件类规模的增大你会发现,当传统测试办法越来越捉襟见肘,穷于对付时,基于测试框架的测试技术仍然"说笑自如".当然别人这么说,我们也不该当即刻就坚信不疑,迷惑永久是值得推崇的科学精神,我们应当通过自己的实践却真逼真切地领会这种改良所带来的欢愉.