JBuilder2200520单元测试体验.docVIP

JBuilder 2005 单元测试体验白盒测试是软件工程中重要的概念，开发人员往往要花1/3时间测试自己编写的程序。一个类所有开放的API接口都必须通过白盒测试，JBuilder集成了目前流行的JUnit单元测试框架，提供了创建、运行、编译测试用例的支持。自动测试代码的重要性一个产品只有通过检验才能投放市场，同样的，一个业务类也只有在经验测试后才能保证功能的正确性，以便被其他类或程序调用，否则隐藏其中的Bug就蔓延开了。业务功能点测试是测试人员的职责，但业务类API的正确性必须由开发人员保证。　一个产品只有通过检验才能投放市场，同样的，一个业务类也只有在经验测试后才能保证功能的正确性，以便被其他类或程序调用，否则隐藏其中的Bug就蔓延开了。业务功能点测试是测试人员的职责，但业务类API的正确性必须由开发人员保证。　　回忆一下最近你所开发的系统，往往一个最难忘的情节是通宵达旦地毯式搜索某个刁专的Bug，历尽千辛万苦，最终找到并解决了它。查找一个隐藏的Bug往往是踏破铁蹄无觅处，而找到后却是：解决全不费功夫。　　造成这尴尬窘局有以下几点原因：　　其一是使用增量式测试策略，即先编写功能代码，在模块开发完毕后才回过头来编写测试用例，因为一个功能模块可能包含许多相互关联的类，形成了层层调用，交错复杂的调用网络，一旦发现了Bug，只得查户口似的逐一排查，其艰辛程度可想而知。　　其二是使用不正确的测试方法，如在每个类中提供一个main 测试函数，对类中的功能方法进行测试，通过运行类的main 方法查看类功能的正确性。在某种程序上，这或许是一个值得赞扬的工作习惯，但工作方式却不足取。因为每个类都必须单独运行，以执行其测试功能，并由开发人员观察测试的正确性。随着程序规模的扩大，类数目直线上升，原有的类也会发生代码的调整，一些功能点可能就变成了漏网之鱼，变成了茫茫类海里的黑户口，将来违法乱纪起来就很难监控了。　　针对这些传统测试思想的不足，测试先行、频繁测试、自动测试的测试思想被越来越多的开发人员所接受并付诸实践。　　测试先行乍听起来有点让人不可思议，一件东西还没有做出来就想着怎么去测试它？仔细分析，这并不荒唐，因为这让你在设计类时，站在调用者的角度去理解类的对外接口，迫使你深入理解类的外在关系，考虑接口的用途，而在具体编写程序时才去具体考虑内部实现细节，这样设计出接口将更易使用，结构也会更趋合理。　　频繁测试，即指测试不应当是阶段性的工作，而应当在程序编写过程中不断进行。因为系统中的类之间往往都存在较多的关联关系，当更改了类的功能时，往往会有多个类受到直接或间接的影响。所以你应该频繁测试以及早发现这种因功能、调整而引起的Bug，越早发现错误解决它的代价越小。频繁测试也是XP编程的一个重要环节，XP编程总让人觉得他们注重功能实现而忽视测试，其实他们也非常关注测试，毕竟测试可以使他们尽可能快的稳步前进。　　所谓自动测试并不是说有一个工具可以让你像安检器一样，自动测试出你类中的问题。而是指应用一定的测试框架，为每个业务类编写独立的测试用例，类代码调整后，对应的测试用例同步调整。多个测试用例组成一个测试套件一起批量运行，它们就像一个强大的Bug嗅探器，一旦发现Bug就会输出特定的信息报告错误，只要一个测试用例没有通过测试就说明程序中有问题。测试用例中所包含的测试规则完成由你定制，这个测试套件对Bug嗅探的灵敏度完全取决于测试用例的测试规则，框架提供编写和运行测试用例的规范性方法。　　在编写一个业务类时，需要相应编写对应的测试用例，一开始挺招惯性定律抵触的，因为它要求你将创建一个测试用例类，似乎需要更多的工作。但你的付出是会得到加倍回报的，随着软件类规模的增大你会发现，当传统测试方法越来越捉襟见肘，穷于应付时，基于测试框架的测试技术依然谈笑自如。当然别人这么说，我们也不应当马上就深信不疑，疑惑永远是值得推崇的科学精神，我们应该通过自己的实践却真真切切地体会这种改进所带来的快乐。JUnit测试框架　JUnit是由Erich Gamma和Kent Beck开发的开源测试框架，JBuilder集成了这个框架并做了扩展。JUnit之所以流行并为广大的开发人员所推崇，一是它实战性强，功能强大，二是它实在简单。一个产品或框架要能有生命力，最好都具备这样的特点。简单的框架　　JUnit是由Erich Gamma和Kent Beck开发的开源测试框架，JBuilder集成了这个框架并对此做了扩展。JUnit之所以流行并为广大的开发人员所推崇，一是因为它实战性强，功能强大，二是因为它实在简单。一个产品或框架要能有生命力，最好都具备这样的特点。　　简单地讲这个框架提供了许多断言（assert）方法，允许你设置测试的规则，如：