JBuilder 2005单元测试之慨述

核心提示：一个产品只有通过检验才能投放市场，同样的，JBuilder 2005单元测试之慨述，一个业务类也只有在经验测试后才能保证功能的正确性，以便被其他类或程序调用，我们也不应当马上就深信不疑，迷惑永远是值得推崇的科学精神，否则隐藏其中的Bug就蔓延开了，业务功能点测试是测试人员的职责

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

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

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

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

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

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

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

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

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

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