|
知识路径: > 测试技术的分类 > Web应用测试 > Web应用开发测试 > 使用Junit进行单元测试 >
|
相关知识点:4个
|
|
|
|
在通常的测试中,一个单元测试一般针对于特定对象的一个特定特性,例如,假定编写了一个针对特定数据库访问的连接池的类包实现,则要建立以下的单元测试。
|
|
|
. 在连接池启动后,是否根据定义的规则在池中建立了相应数量的数据库连接;
|
|
|
. 申请一个数据库连接,是否根据定义的规则从池中直接获得缓存连接的引用,还是建立新的连接;
|
|
|
. 释放一个数据库连接后,连接是否根据定义的规则被释放以便以后使用;
|
|
|
. 后台Housekeeping线程是否按照定义的规则释放已经过期的连接申请;
|
|
|
. 如果连接有时间期限,后台Housekeeping线程是否定期释放已经过期的缓存连接。
|
|
|
这里只列出了部分的可能测试,但是可以看出单元测试的粒度。一个单元测试基本是以一个对象的明确特性为基础,单元测试的过程应该限定在一个明确的线程范围内。根据上面所述,一个单元测试的测试过程非常类似于一个Use Case的定义,但是单元测试的粒度一般来说比Use Case的定义要小,这点是容易理解的。因为Use Case是以单独的事务单元为基础的,而单元测试是以一组聚合性很强的对象的特定特征为基础的。一般而言,一个事务中会利用许多的系统特征来完成具体的软件需求。
|
|
|
从上面的分析可以得出,测试单元应该把一个对象的内部状态的转换为基本编写单元。一个软件系统就和一辆设计好的汽车一样,系统的状态是由同一时刻系统内部的各个分立的部件的状态决定的,因此为了确定一个系统最终的行为符合要求,我们首先需要保证系统内的各个部分的状态会符合我们的设计要求,所以我们的测试单元的重点应该放在确定对象的状态变换上。
|
|
|
然而,需要注意的并不是所有的对象组特征都需要被编写成独立的测试单元,应该在有可能引入错误的地方引入测试单元,通常这些地方存在于有特定边界条件、复杂算法以及需求变动比较频繁的代码逻辑中。除了这些特性需要被编写成独立的测试单元外,还有一些边界条件比较复杂的对象方法也应该被编写成独立的测试单元,这部分单元测试已经在Junit文档中被较好地描述和解释过了。
|
|
|
在基本确定了需要编写的单元测试之后,我们还应该问自己:编写好了这些测试,我们是否可以有把握地告诉自己,如果代码通过了这些单元测试,我们能认定程序的运行是正确的,符合需求的。如果我们不能非常地确定,就应该看看是否还有遗漏的需要编写的单元测试,或者重新审视我们对软件需求的理解。通常来说,在开始使用单元测试的时候,大多数单元测试总是没有错误的。
|
|
|
一旦我们确定了需要编写的测试单元,接下来就应该着手编写。
|
|
|