如何进行单元测试(4)

　　表2

　　4.2 测试类设计

　　一个模块或一个方法(Method)并不是一个独立的程序，在考虑测试它时要同时考虑它和外界的联系，用些辅助模块与所测模块相联系的其他模块。这些辅助模块分为两种：

　　1. 驱动模块(driver):相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实际测试结果。

　　2. 桩模块(stub):用于代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不容许什么事情也不做。

　　所测模块与它相关的驱动模块及桩模块共同构成了一个“测试环境”，如图2。驱动模块和桩模块的编写会给测试带来额外的开销。因为它们在软件交付时不作为产品的一部分一同交付，而且它们的编写需要一定的工作量。特别是桩模块，不能只简单地给出“曾经进入”的信息。为了能够正确的测试软件，桩模块可能需要模拟实际子模块的功能，这样桩模块的建立就不是很轻松了。

　　图2 单元测试的测试环境

　　编写桩模块是困难费时的，其实也是完全可以避免编写桩模块的;只需在项目进度管理时将实际桩模块的代码编写工作安排在被测模块前编写即可。而且这样可以提高测试工作的效率，提高实际桩模块的测试频率从而更有效的保证产品的质量。但是，为了保证能够向上一层级提供稳定可靠的实际桩模块，为后续模块测试打下良好的基础，驱动模块还是必不可少的。

　　对于每一个包或子系统我们可以根据所编写的测试用例来编写一个测试模块类来做驱动模块，用于测试包中所有的待测试模块。而最好不要在每个类中用一个测试函数的方法，来测试跟踪类中所有的方法。这样的好处在于：

　　1. 能够同时测试包中所有的方法或模块，也可以方便的测试跟踪指定的模块或方法。

　　2. 能够联合使用所有测试用例对同一段代码执行测试，发现问题。

　　3. 便以回归测试，当某个模块作了修改之后，只要执行测试类就可以执行所有被测的模块或方法。这样不但能够方便得检查、跟踪所修改的代码，而且能够检查出修改对包内相关模块或方法所造成的影响，使修改引进的错误得以及时发现。

　　4. 复用测试方法，使测试单元保持持久性，并可以用既有的测试来编写相关测试。

　　5. 将测试代码与产品代码分开，使代码更清晰、简洁;提高测试代码与被测代码的可维护性。

原文转自：http://www.ltesting.net