JBuilder 2005单位测试之慨述

一个产物只有通过检讨才气投放市场，同样的，一个业务类也只有在履历测试后才气担保成果的正确性，以便被其他类或措施挪用，不然埋没个中的Bug就伸张开了。业务成果点测试是测试人员的职责，但业务类API的正确性必需由开拓人员担保。

回想一下最近你所开拓的系统，往往一个最难忘的情节是通宵达旦地毯式搜索某个刁专的Bug，历尽千辛万苦，最终找到并办理了它。查找一个埋没的Bug往往是踏破铁蹄无觅处，而找到后却是：办理全不费工夫。

造成这难过窘局有以下几点原因：

其一是利用增量式测试计策，即先编写成果代码，在模块开拓完毕后才回过甚来编写测试用例，因为一个成果模块大概包括很多彼此关联的类，形成了层层挪用，交织巨大的挪用网络，一旦发明白Bug，只得查户口似的逐一排查，其艰苦水平可想而知。

其二是利用不正确的测试要领，如在每个类中提供一个main()测试函数，对类中的成果要领举办测试，通过运行类的main()要领查察类成果的正确性。在某种措施上，这或者是一个值得赞扬的事情习惯，但事情方法却不敷取。因为每个类都必需单独运行，以执行其测试成果，并由开拓人员调查测试的正确性。跟着措施局限的扩大，类数目直线上升，原有的类也会产生代码的调解，一些成果点大概就酿成了丧家之犬，酿成了茫茫"类"海里的黑户口，未来"违法乱纪"起来就很难监控了。

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

测试先行乍听起来有点让人不行思议，一件对象还没有做出来就想着怎么去测试它？仔细阐明，这并不荒诞，因为这让你在设计类时，站在挪用者的角度去领略类的对外接口，迫使你深入领略类的外在干系，思量接口的用途，而在详细编写措施时才去详细思量内部实现细节，这样设计出接口将更易利用，布局也会更趋公道。

频繁测试，即指测试不应当是阶段性的事情，而该当在措施编写进程中不绝举办。因为系统中的类之间往往都存在较多的关联干系，当变动了类的成果时，往往会有多个类受到直接或间接的影响。所以你应该频繁测试以赶早发明这种因成果、调解而引起的Bug，越早发明错误办理它的价钱越小。频繁测试也是XP编程的一个重要环节，XP编程总让人以为他们注重成果实现而忽视测试，其实他们也很是存眷测试，究竟测试可以使他们尽大概快的稳步前进。

所谓自动测试并不是说有一个东西可以让你像安检器一样，自动测试出你类中的问题。而是指应用必然的测试框架，为每个业务类编写独立的测试用例，类代码调解后，对应的测试用例同法式整。多个测试用例构成一个测试套件一起批量运行，它们就像一个强大的Bug嗅探器，一旦发明Bug就会输出特定的信息陈诉错误，只要一个测试用例没有通过测试就说明措施中有问题。测试用例中所包括的测试法则完成由你定制，这个测试套件对Bug嗅探的"敏捷度"完全取决于测试用例的测试法则，框架提供编写和运行测试用例的类型性要领。

在编写一个业务类时，需要相应编写对应的测试用例，一开始挺招"惯性定律"抵触的，因为它要求你将建设一个测试用例类，好像需要更多的事情。但你的支付是会获得更加回报的，跟着软件类局限的增大你会发明，当传统测试要领越来越捉襟见肘，穷于应付时，基于测试框架的测试技能依然"谈笑自如"。虽然别人这么说，我们也不应当顿时就深信不疑，迷惑永远是值得推崇的科学精力，我们应该通过本身的实践却真真切切地体会这种改造所带来的快乐。