unitils使用DatabaseModule和DbUnitModule的数据库测试

通过DbUnit来管理测试数据

@DataSet
public class UserDAOTest extends UnitilsJUnit4 {
    @Test
    public void testFindByName() {
        User result = userDao.findByName("doe", "john");
        assertPropertyLenientEquals("userName", "jdoe", result);
    }
}

在测试代码中加入@DataSet标签，Unitils就会为测试代码找测试需要的DbUnit数据文件。如果没有指定文件名，Unitils会自动在测试类目录下查找以className.xml格式命名的测试数据集文件。

数据集文件将采用DbUnit'sFlatXMLDataSet文件格式并包含测试需要的所有数据。

表中的所有数据集的内容首先将被删除，然后所有数据集中的数据将被插入到表中，数据集里没有的表将不会被清空。

如果你想清空指定的表，可以在数据集文件里添加一个空的表元素，

比如在数据集文件里添加<MY_TABLE/>，如果你想指定为一个null值，你可以用【null】设置。

<dataset>
	<usergroup name="admin" />
	<usergroup name="sales " />
	<user userName=jdoe " name="doe" firstname="john" userGroup="admin" />
	<user userName=smith " name="smith" userGroup="sales" />
</dataset>

首先会清空usergroup和user的表内容，然后把数据集文件的内容插入到usergroup和

user表里，名字为smith的user的firstname被设置为null。

配置数据集加载策略

默认的数据集加载到数据库里采用cleaninsert策略，也就是先把数据库中的数据clean，然后把数据集的数据insert到数据库。

详细的过程是：数据集里有的表都会在数据库中清空，然后把数据集里的测试数据插入到表中。

这种行为是可以被配置的，通过修改属性DbUnitModule.DataSet.loadStrategy.default可以实现。

比如我们在unitils.properties中修改如下属性：

DbUnitModule.DataSet.loadStrategy.default=org.unitils.dbunit.datasetloadstrategy.InsertLoadStrategy

这种策略是用insert代替cleaninsert，也就是数据集里的表在数据库里不被删除而只是把数据集里的测试数据插入到数据库中。

这种加载策略也可以在特定的测试用例上使用，通过修改@DataSet标签的属性值。

@DataSet(loadStrategy=InsertLoadStrategy.class)

因为这个和DbUnit是类似的，采用不同的加载策略就是使用不同的数据库操作。

默认支持的加载策略。

•CleanInsertLoadStrategy:数据集里有的表在数据库中都要把数据删掉，然后把数据集里的数据插入到数据库中。

•InsertLoadStrategy：就是简单的把数据集里的数据插入到数据库中。

•RefreshLoadStrategy：用数据集里的数据更新数据库中的数据。也就是：数据集里有数据库也有的数据被更新，数据集里有而数据库里没有的数据被插入，数据库里面有而数据集里没有的数据保持不变。

•UpdateLoadStrategy：用数据集里的数据更新数据库里的数据，如果数据集里的数据不在数据库中那么失败（比如一条数据拥有相同的主键值）。

DatabaseModule连接到测试数据库

我们测试数据库用到的数据源来自哪里，并且我们怎么让我们测试的DAO类来使用我们的数据源。

当我们开始我们的测试实例的时候，Unitils会根据unitils.properties中定义的属性来创建一个数据源实例，连接到我们的测试数据库。

随后的数据库测试会重用相同的数据源实例。

建立连接的细节定义在下面的属性里：

database.driverClassName=oracle.jdbc.driver.OracleDriver

database.url=jdbc:oracle:thin:@yourmachine:1521:YOUR_DB

database.userName=john

database.password=secret

database.schemaNames=test_john

我们在工程的unitils.properties文件里设置driver和url这两个属性，这是为整个工程使用的属性。

如果特定用户使用的属性我们可以设置在unitils-local.properties文件里，比如user,password和schema，这样每个开发者就使用自己定义的测试数据库的schema,而且彼此之间也不回产生影响。

在一个测试被建立之前，数据源要注入到测试实例中：

如果在一个属性或者setter方法前发现@TestDataSource标签就会设置

你必须为你的测试代码加上配置代码，好让你的测试类使用数据源，一般的都通过继承一个基类实现数据库测试，下面就是一个典型基类的代码：

public abstract class BaseDAOTest extends UnitilsJUnit4 {

    @TestDataSource
    private DataSource dataSource;

    @Before
    public void initializeDao() {
        BaseDAO dao = getDaoUnderTest();
        dao.setDataSource(dataSource);
    }

    protected abstract BaseDAO getDaoUnderTest();
}

上面的例子是用一个标签来获得数据源的引用，调用DatabaseUnitils.getDataSource()方法也可以达到相同的目的。

一般在我们的开发项目中，只有dbUnit中的@DataSet会使用unitils.dataset提供的数据源。

dao的数据源配置在datasource-test.xml中，这样会是两个数据源。

事务（Transactions）

默认情况下每一次测试都执行一个事务，在测试结束的时候commit。

这种默认情况可以通过unitils.properties修改属性来改变，比如：

DatabaseModule.Transactional.value.default=disabled

这个属性的其他合法设置值可以是：commit,rollback和disabled。

事务的行为也可以通过加入@Transactional标签，在测试类级别修改。比如：

@Transactional(TransactionMode.ROLLBACK)

public class UserDaoTest extends UnitilsJUnit4{}

这样的话，在每一次测试结束后都会回滚，@Transactional这个标签是可继承的，所以可以在公共父类里定义，而不是在每个类里单独定义。

Dao和unitils是使用两套数据源。只是在加事务时，会公用事务，发生事务传播。

在test层，加事务管理，会和bo层的事务发生事务传播。

默认的事务传播属性为：当前有事务，就使用当前的事务，两者公用一个事务。

所以，当bo层抛异常时，声明式事务就会抛 Transaction rolled back because it has been marked as rollback-only异常。

原来是这样设置的：

<tx:attributes> <tx:method name="*" read-only="true"/> </tx:attributes>

发现selectA调用selectB，如果selectB抛出Exception，selectA中捕获Exception但是并不继续向外抛出，最后会出现错误。

Transaction rolled back because it has been marked as rollback-only

纠其原理其实很简单，在selectB返回的时候，transaction被设置为rollback-only了，但是selectA正常消化掉，没有继续向外抛。

那么selectA结束的时候，transaction会执commit操作，但是 transaction已经被设置为 rollback-only了。

所以会出现这个错误。

解决方法：不要吃异常，有异常就往外抛，用于回滚事务。

应用Spring测试

Unitils提供了以下支持Spring的特性：

•ApplicationContext配置的管理

•在单体测试代码中注入Spring的Beans

•使用定义在Spring配置文件里的HibernateSessionFactory

•引用在Spring中配置Unitils数据源

ApplicationContext配置

可以简单的在一个类，方法或者属性上加上@SpringApplicationContext标签，并用Spring的配置文件作为参数，来加载应用程序上下文。

下面就是一个例子：

public class UserServiceTest extends UnitilsJUnit4 {
    @SpringApplicationContext({ "spring-config.xml", "spring-test-config.xml" })
    private ApplicationContext applicationContext;
}

Unitils会尽可能的重用应用程序上下文，比如下面的例子没有加载新的配置文件，所以就重用相同的实例。

@SpringApplicationContext("spring-beans.xml")
public class BaseServiceTest extends UnitilsJUnit4 {
}
public class UserServiceTest extends BaseServiceTest {
@SpringApplicationContext
private ApplicationContext applicationContext;
}
public class UserGroupServiceTest extends BaseServiceTest {
@SpringApplicationContext
private ApplicationContext applicationContext;
}

在父类 BaseServiceTest 里指定了配置文件，应用程序上下文会创建一次，然后在子类UserServiceTest 和 UserGroupServiceTest 里会重用这个应用程序上下文。

因为加载应用程序上下文是一个非常繁重的操作，如果重用这个应用程序上下文会大大提升测试代码的性能。

注入Spring的Beans

只要配置好了应用程序上下文，所有以@SpringBean , @SpringBeanByType或者@SpringBeanByName注释的fields/setters都会注入beans,

下面的例子展示了如何根据应用程序上下文来获得UserService bean实例。

@SpringBean("userService")

private UserService userService;

@SpringBeanByName

private UserService userService;

@SpringBeanByType

private UserService userService;

用@SpringBean标签你可以从应用程序上下文得到一个具有独一无二名字的Spring的bean,

@SpringBeanByName 这个标签效果相同，只是它根据类 field 名称来区分 bean。

当使用@SpringBeanByType 标签的时候，应用程序上下文会查找一个和 filed 类型相同的bean,

这个例子中，会查找UserService类或者子类的bean，如果这样的bean不存在或者不只找到一个结果，那么抛出异常。

unitils使用DatabaseModule和DbUnitModule的数据库测试

猜你喜欢