9

通向架构师的道路（第二十五天）SSH的单元测试与dbunit的整合

 3 years ago
source link: https://blog.csdn.net/lifetragedy/article/details/8251056
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

通向架构师的道路（第二十五天）SSH的单元测试与dbunit的整合

original.png
TGITCIC 2012-12-03 15:31:59 articleReadEyes.png 15492

在二十三天中我们介绍了使用maven来下载工程的依赖库文件，用ant来进行war包的建立。今天我们在这个基础上将使用junit+dbunit来进行带有单元测试报告的框架的架构。

  1. 每次打包之前自动进行单元测试并生成单元测试报告
  2. 生成要布署的打包文件即war包
  3. 单元测试的代码不能够被打在正式的要布署的war包内，单元测试仅用于unit test用
  4. 使用模拟数据对dao层进行测试，使得dao方法的测试结果可被预料

二、Junit+Ant生成的单元测试报告

上面是一份junit生成的测试报告，它可以与ant任务一起运行然后自动生成这么一份html的测试报告，要生成这样的一份junit test report我们需要调用ant任务中的<junitreport>这个task，示例代码如下： 
<target name="junitreport">
	<junit printsummary="on" haltonfailure="false" failureproperty="tests.failed" showoutput="true">
		<classpath>
			<pathelement path="${dist.dir}/${webAppQAName}/WEB-INF/classes" />
			<fileset dir="${lib.dir}">
				<include name="*.jar" />
			</fileset>
			<fileset dir="${ext-lib.dir}">
				<include name="*.jar" />
			</fileset>
		</classpath>
		<formatter type="xml" />
		<batchtest todir="${report.dir}">
			<fileset dir="${dist.dir}/${webAppQAName}/WEB-INF/classes">
				<include name="org/sky/ssh/ut/Test*.*" />
			</fileset>
		</batchtest>
	</junit>
	<junitreport todir="${report.dir}">
		<fileset dir="${report.dir}">
			<include name="TEST-*.xml" />
		</fileset>
		<report format="frames" todir="report" />
	</junitreport>
	<fail if="tests.failed">
		---------------------------------------------------------
		One or more tests failed, check the report for detail...
		---------------------------------------------------------
	</fail>
</target>

在一般的产品级开发时或者是带有daily building/nightly building的项目组中我们经常需要检查最新check in的代码是否影响到了原有的工程的编译，因为每天都有程序员往源码服务器里check in代码，而有时我们经常会碰到刚刚被check in的代码在该程序员本地跑的好好的，但是check in源码服务器上后别人从源码服务器“拉”下来的最新代码跑不起来，甚至编译出错，这就是regression bug，因此我们每天的打包要干的事情应该是：
  1. 程序员check in代码时必须把相关的unit test也check in源码服务器
  2. 次日的零晨由持续集成构件如：cruisecontrol自动根据设好的schedule把所有的源码服务器的代码进行编译
  3. 运行单元测试
  4. 打包布署到QA服务器上去
如果考究点的还会生成一份“单元测试覆盖率”报告。
那么有了这样的单元测试报告，项目组组长每天早上一上班检查一下单元测试报告就知道昨天代码check in的情况，有多少是成功多少是失败，它们分别是哪些类，哪些方法，以找到相关的负责人。
同时，有了单元测试报告，如果测试报告上显示的是有fail的地方，该版本就应被视之为fail，不能被送给QA进行进一步的测试，直到所有的单元测试成功才能被送交QA。

三、如何在Spring下书写一个单元测试方法

3.1使用spring的注入特性书写一个单元测试

Spring是一个好东西，一切依赖注入，连单元测试都变成了依赖注入了，这省去我们很多麻烦。
我们可以将web工程中的applicationContext、Datasource甚至iBatis或者是Hibernate的配署都可以注入给junit，这样使得我们可以用IoC的方法来书写我们的单元测试类。
此处，我们使用的junit为4.7, 而相关的spring-test库文件为3.1，我都已经在pom.xml文件中注明了.
我们先在eclipse里建立一个专门用来放单元测试类的src folder：test/main/java。
注意一下单元测试类的coding convention：
  • 所有的测试类必须以Test开头
  • 所有的测试方法名必须为public类型并且以test开头
  • 所有的测试类全部放在test/main/java目录下，不可和src/main/java混放

类 org.sky.ssh.ut.BaseSpringContextCommon

该类为一个基类，我们所有的单元测试类全部需要继承自该类，大家可以把这个类认为一个spring的context加载器， 注意这边的datasource.xml。
因为我们在做测试方法时势必会涉及到对一些数据进行操作，因此我们在数据库里除了平时开发和布署用的数据库外，还有一个专门用于运行“单元测试”的“单元测试数据库”或者“单元测试数据库 实例”，因此我们在单元测试时会把我们当前的数据库连接“硬”指向到“单元测试用数据库”上去.
这个datasource.xml文件位于/org/sky/ssh/ut/ds目录下，见下图（当然它也必须被放在test/main/java目录里哦：
该文件内容如下：

org.sky.ssh.ut.ds.datasource.xml

注意两行:
<property name="user" value="alpha_test" />

<property name="password" value="password_1" />
可以得知我们测试时用的是同一个数据库上的另一个实例，该实例是专门为我们的单元测试用的.

我们先来书写一个单元测试类吧

org.sky.ssh.ut.TestLoginDAO

很简单吧，把原来的LongDAO注入进我们的单元测试类中，然后在test方法前加入一个@Test代码该方法为“单元测试”方法即可被junit可识别，然后我们调用一下LoginDAO中的.validLogin方法，测试一下返回值。

运行方法为：

在eclipse打开该类的情况下右键->run as Junit Test

然后选junit4来运行，运行后直接出错抛出：

这样一个错误，为什么？

其原因在于我们的工程是在eclipse里使用的m2 eclipse这个插件生成的，因此在做单元测试时由于我们的unit test的类是放在test/main/java这个目录下，而这个目录是我们手工建的，因此eclipse不知道这个目录的对应的编译输出的class的目录了.

没关系，按照下面的方法：

右键->选择run as->run configuration，打开如下的设置

选择classpath这个选项栏

  1. 单击user Entries
  2. 单击Advanced按钮
  3. 在弹出框中选择Add Folders
  4. 点ok按钮
在下一个弹出框中选择我们的junit test的源码在被编译后输出的目录即myssh2工程的WebContent/WEB-INF/classes目录，对吧。
点OK按钮
点Apply按钮
点Run按钮，查看运行效果
运行成功，说明该unit test书写的是对的。

3.2 结合dbunit来做单元测试

我们有了junit为什么还要引入一个dbunit呢？这不是多此一举吗？

试想一下下列场景：

我们开发时连的是开发用的数据库，一张表里有一堆的数据，有些数据不是自己的插的是其它的开发人员插的，那么我想要测试一个dao或者是service方法，获得一个List，然后判断这个List里的值是否为我想要的时候，有可能会碰到下属这样的情况：

运行我的service或者dao方法得到一个list，该list含有6个值，但正好在运行时另一个开发人员因为测试需要往数据库里又插了一些值，导致我的测试方法失败，对不对，这种情况是有可能的。

怎么办呢？比较好的做法是我们需要准备一份自己的业务数据即prepare data，因为是我们自己准备的数据数据，因此它在经过这个方法运行后得到的值，这个得到的值是要经过一系列的业务逻辑的是吧？因此这个得到的值即：expected data是可以被精确预料的。

因此，我们拿着这个expected data与运行了我们的业务方法后得到的结果进行比对，如果比对结果一致，则一定是测试成功，否则失败，对吧？

这就是我们常说的，测试用数据需要是一份干净的数据。

那么为了保持我们的数据干净，我们在测试前清空我们的业务表，插入数据，运行测试地，比对结果，删除数据（也可以不删除，因为每次运行时都会清空相关的业务表），这也就是为什么我们事先要专门搞一个数据库或者是数据库实例，在运行单元测试时我们的数据库连接需要指向到这个单元测试专用的数据库的原因了，见下面的测试流程表：

有了DbUnit，它就可以帮助我们封装：

  • 准备测试用数据
  • 清空相关业务表
  • 插入测试数据
  • 清除先前插入的业务数据
这一系列底层的操作。
现在我们可以开始搭建我们的单元测试框架了，下面是这个单元测试框架的”逻辑表达图“（一个架构设计文档不仅需要有logic view还要有physical view。。。当然还有更多，以后会一点点分享出来）
这边的Session Factory是结合的原有框架的Hibernate的Session Factory，我们也可以把它改成iBatis，Jdbc Template等等等。。。它可以稍作变动就可适用于一切SSX这样的架构。
该框架的优点如下：

3.3 构建spring+junit+dbunit的框架

除去上述的一些类和配置我们还需要3个基类，它们分别位于test/main/java目录下（因为它们都属于unit test对吧）

org.sky.ssh.ut.util.CleanTableXmlAdapter

org.sky.ssh.ut.util.TableBean

org.sky.ssh.ut.util.XmlUtil

3.4使用框架

我们准备两份测试用数据

test_del_table.xml文件

test_insert_table.xml文件

测试类org.sky.ssh.ut.TestStudentService

  1. 该测试方法每次都清空t_student表
  2. 往t_student表里注入5条数据
  3. 运行业务方法getAllStudent
  4. 比较getAllStudent方法返回的list里的size是否为5
  5. 清空注入的数据（也可不用去清空）
然后我们在eclipse里用junit来运行我们这个测试类吧。
我们现在用我们的单元测试用数据库帐号连入我们的数据库，查询t_student表
我们往该表中手动插入一条数据
再重新运行一遍我们的单元测试
测试结果还是成功，再重新连入我们单元测试用数据库实例查询t_student表，发觉还是5条记录，说明我们的框架达到了我们的目标。

四、将ant与我们的单元测试框架连接起来并生成单元测试报告

先来看一下我们的nightly building，即每天次日的零晨将要生成的单元测试与打包布署的流程吧
(需要ant1.8及以上版本运行)
然后下面给出build.xml文件(需要ant1.8及以上版本运行)（结合了maven的依赖库机制）

build.properties文件

# ant
appName=myssh2
webAppName=myssh2
webAppQAName=myssh2-UT
local.dir=C:/eclipsespace/${appName}
src.dir=${local.dir}/src/main/java
test.src.dir=${local.dir}/test/main/java
dist.dir=${local.dir}/dist
report.dir=${local.dir}/report
webroot.dir=${local.dir}/src/main/webapp
lib.dir=${local.dir}/lib
ext-lib.dir=${local.dir}/ext-lib
classes.dir=${webroot.dir}/WEB-INF/classes
resources.dir=${local.dir}/src/main/resources

build.xml文件

对照着上面的build的流程图，很容易看懂
打开一个command窗口，进入到我们的工程的根目录下，设置好ANT_HOME并将%ANT_HOME%\bin目录加入到path中去，然后在工程的根据目录下运行ant，就能看到打包和运行unit test的效果了。
build完后可以在工程的根目录下找到一个report目录，打开后里面有一堆的html文件
双击index.htm这个文件查看单元测试报告
我们在windows的资源管理器中打开我们的工程，在根目录下有一个dist目录，打开这个目录，我们会开到两个目录与一个.war文件，它们分别是：
其中myssh2-UT是专门用来run unit test的，而myssh2是可以用于发布到production environment的，我们打开myssh2.war这个包，我们可以看到，由于这个是正确布署的war，因此里面是不能够含有unit test的相关类与方法的，完全按照上述的打包流程图来做的。
结束今天的教程！！！

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK