本文从DBUnit开始介绍一系列测试工具,无论是旧*,还是新*... Utilities-DBUnit、Spring-test-dbunit 都不放过,但最后亮出新利器......
1-DBUNIT
数据库测试工具事实上的标准就是DBUnit。根据http://www.dbunit.org/的介绍,其1.0版本早在2002年就已经发布。
它只需要一个JDBC的连接,就能完成对数据状态的控制。
IDatabaseConnection con = new DatabaseConnection(DbUtil.getConnection())
另外一个其核心概念是IDataSet,通过DataSet来表示数据库,用ITable 表示来自来自数据库或者测试用例的表和数据
IDataSet dataset = new FilteredDataSet(filter, connection.createDataSet());
FlatXmlDataSet.write(dataset, new FileOutputStream(file));
上述操作完成了将数据库内容导出到了一个DBUnit自定义的XML文件中。
ITable actualTable = getConnection().createDataSet().getTable(_testTableName);
IDataSet expectedDataSet = new FlatXmlDataSet(new File(_testDir, _dbFile));
ITable expectedTable = expectedDataSet.getTable(_testTableName);
Assertion.assertEquals(expectedTable, actualTable);
此外,上述操作完成了来自用例的预期结果expectedTable和运行时来自数据库的结果进行比对actualTable。
另外,DBUnit还提供了在数据库读取、插入数据时的操作
DatabaseOperation.UPDATE
DatabaseOperation.DELETE
DatabaseOperation.DELETE_ALL
DatabaseOperation.TRUNCATE
DatabaseOperation.REFRESH
DatabaseOperation.CLEAN_INSERT
DatabaseOperation.NONE
以及非常实用的数据排序、筛选、忽略等fancy的功能,并支持了xml、csv、excel等数据保存格式,甚至还设计了DBUnit自定义的Assertion。让其成为一个非常成功的数据库测试框架和数据导入导出操作工具。并且成功地吸引了Unitils这样的测试框架将其作为数据库测试模块的底层工具。
DBUnit存在的问题-维护少,升级、发布慢,
从发布历史来看,DBUnit在发布的前2年,保持了非常频繁的更新,在发布了2.0版本之后,可能维护者认为,数据库测试的方案已经完整了,已经没什么新功能可做了,其更新速度就开始下降。对应的,其Google热度也逐步下降。
但是,目前还依然顽强地维持着更新,最近三年基本上是每年一发布一个版本的节奏,解决着一些缺陷,缺少架构层面的重大更新。
2-Spring-test-dbunit
从上述介绍中可以看出,DBUnit虽然功能强大,但是为了完成测试数据的导入和预期结果的比较,还是需要写一定量的代码的。随着Spring框架逐步成为MVC开发模式的事实上的标准,统治JAVA WEB类的项目,基于注解的开发方式流行了开来。于是,一个基于DBUnit的新框架spring-test-dbunit横空出世,提供了Spring Test Framework与DBUnit之间的集成,实现注解驱动的数据库集成测试方式。
@Test
@DatabaseSetup(value = "insert.xml")
@DatabaseSetup(connection="customerDataSource", value="insert-custs.xml")
public void testInsert() throws Exception {
// Inserts "insert.xml" into dataSource and "insert-custs.xml" into customerDataSource
// ...
}
优势:
引入了@DatabaseSetup
@DatabaseTearDown
@ExpdectedDatabase
等注解,将dbunit引入了Spring的圈子。
劣势
问题1-维护慢,最近一个bug修复是在17年12月
问题-2:只能在Spring技术栈下使用
想要用注解,得先把Spring带上。不像DBUnit那样可以独立使用。
问题-3:只能在Spring技术栈下使用数据结构单一,只支持了xml格式,其余格式需要自行开发
@DatabaseSetup("sampleData.xml")
问题4:只能在Spring技术栈下使用使用的是较老的dbunit版本
这是16年初发布的DBUnit版本。
3-database-rider
这是笔者最近才发现的一个新的基于DBUnit的扩展框架。根据changelog, 该框架于2015年启动开发,2016年中发布1.0版本,团队还为此发送了一个 1.0 promo video 。
优势1:DBUnit Spring-test-dbunit
首先,这还是一个基于DBUnit的框架
,具备了DBUnit的基本功能,其次还吸收了Spring-test-dbunit基于注解的特性。基本上所有的数据库操作都可以通过注解来完成,如下例:
@Test
@DataSet(transactional=true)
@ExpectedDataSet(value = "yml/expectedUsers.yml",ignoreCols = "id")
public void shouldMatchExpectedDataSet() {
User u = new User();
u.setName("non expected user1");
User u2 = new User();
u2.setName("non expected user2");
emProvider.em().persist(u);
emProvider.em().persist(u2);
}
其次,提供了新的数据格式,json/yaml
如上例所示,数据文件保存在一个yaml文件中。目前json/yaml已经替代xml成为了软件开发时对数据文件的首选,广泛应用于接口数据交换、配置文件等场景。因此Database-rider提供的这一便利应该能吸引到不少对于DBUnit自定义的Flat-format XML文件格式早已不满的用户。
DataBase-Rider中引入了较新的dbunit ,并计划在新版本中引用dbunit2.6.0
详见feature request: update to DBUnit 2.6.0 #111
相对于其竞争对手来说,这个工具在采用新的dbunit版本上还是蛮上心的。
最吸引人的是提供了 @ExportDataset的注解
在数据库测试过程中,一般的典型场景是:
1)测试人员根据测试点设计测试用例数据,包括a)上下文环境 b)输入 c)预期结果。
2)setup,测试人员将基础数据导入数据库,从而控制程序的上下文环境
3) 通过界面、API接口或者存储过程等形式与程序交互,并完成输入。
4)查询数据库结果,并与预期结果进行比对。
而自动化的过程,往往是在上述步骤完成后
5) 将a)上下文环境 b)输入 c)实际结果分别导出
6)编写代码,完成1-4的过程并保存形成自动化用例
7)如有可能,将1-6合并,实现所谓的手自一体的自动化测试
从上述过程来看,提供一个较为方便的数据导出功能,可以大大方便了自动化用例的编写。Database-rider正是解决了DBUnit中需要编写代码去导出数据库中的数据的问题。而Sping-Test-DBunit则很遗憾地忽略了这一重要功能。
劣势- 又一个*,期待合体
本质上这还是基于DBUnit的一个新*,包含了DBUnit使用中会遇到的所有的坑(这个足够写比本文长3倍的文章来吐槽)。其实造一个新*,不如把旧*焕新。期待哪天这两个团队能合并。。。
更新会持久么?
DBUnit热闹了2年,Spring-Test-DBUnit 也类似。凭成员热情,背后没有商业公司支持的开源项目,特别是工具类项目,其持久度是永远的疑问。