JBuilder 2005单元测试之慨述

在产品研发的旅程中，每一款产品都需要经过严格的检验才能走进市场，就像每个业务类也需要通过测试来确保其功能的正确性，以便被其他类或程序顺利调用。否则，潜藏的Bug可能会如野火般蔓延，破坏整个系统的稳定性和安全性。业务功能点的测试是测试人员的责任，但业务类API的准确性则依赖于开发人员的保证。

回想一下我们最近开发的那个系统，往往最令人难忘的那一刻是通宵达旦，如侦探般追踪那狡猾隐蔽的Bug。有时，寻找一个隐藏的Bug如同踏破铁鞋无觅处，但一旦找到，解决它却是全不费功夫。

造成这种尴尬局面的原因有多方面。增量式的测试策略是一大罪魁祸首。在这种策略下，我们先编写功能代码，等到模块开发完毕后再回头编写测试用例。由于一个功能模块可能包含众多相互关联的类，形成一个错综复杂的调用网络，一旦发现了Bug，排查工作就像是在迷宫中寻找出路，艰辛程度难以想象。

不正确的测试方法也是问题的关键。有些开发者可能通过在每个类中提供main()测试函数的方式，对类中的功能方法进行测试。虽然这种习惯在某种程度上值得赞扬，但并不是一种高效的工作方式。因为每个类都需要单独运行以执行其测试功能，随着程序规模的扩大，类数目急剧增加，原有的类也可能因代码调整而遗留一些未被测试的“盲点”，这些盲点就像茫茫“类”海中的黑户口，一旦出现问题就难以监控。

为了应对这些传统测试思想的不足，一种新的测试理念正在被越来越多的开发人员所接受并付诸实践。那就是“测试先行、频繁测试、自动测试”。

测试先行听起来有点反直觉，但在仔细分析后你会发现这其实是一种合理的方法。它要求你在设计类时，从调用者的角度去理解类的对外接口，迫使你深入理解类的外在关系，考虑接口的用途。这样设计出的接口将更易于使用，结构更趋合理。

频繁测试意味着测试不应该是一次性的工作，而应该贯穿于程序编写的整个过程。因为系统中的类之间往往存在较多的关联关系，当更改类的功能时，其他类可能会受到直接或间接的影响。频繁测试有助于及早发现因功能调整而引发的Bug，越早发现错误解决它的代价就越小。

至于自动测试，它并不是指有一个工具可以像安检器一样自动检测出类中的所有问题。而是指应用一定的测试框架，为每个业务类编写独立的测试用例。当类代码调整时，对应的测试用例也会同步调整。多个测试用例组成一个测试套件，一起批量运行。它们就像一个强大的Bug嗅探器，一旦发现Bug就会输出特定的错误信息。只要有一个测试用例没有通过测试，就说明程序中存在问题。

在编写业务类时，需要相应编写对应的测试用例。一开始可能会因为需要创建测试用例类而感到有些麻烦，但随着软件规模的增大，你会发现基于测试框架的测试技术依然能够“谈笑自如”，而传统的测试方法则可能越来越捉襟见肘。只有通过自己的实践，才能真正体会到这种改进所带来的快乐。