1. 下面是一个通用性测试类的写法,自己的单元测试可以参照:想对一个方法的每种异常进行测试的话,应该为每种情况写一个测试方法。
import org.junit.*;
import static org.junit.Assert.*;
public class SampleTest {
private java.util.List emptyList;
/**
* Sets up the test fixture.
* (Called before every test case method.)
*/
@Before
public void setUp() {
emptyList = new java.util.ArrayList();
}
/**
* Tears down the test fixture.
* (Called after every test case method.)
*/
@After
public void tearDown() {
emptyList = null;
}
@Test
public void testSomeBehavior() {
assertEquals("Empty list should have 0 elements", 0, emptyList.size());
}
@Test(expected=IndexOutOfBoundsException.class)
public void testForException() {
Object o = emptyList.get(0);
}
}
2. 如果测试一个类的方法可能抛出多个异常,但一次执行只能抛出一个异常,那么dbunit
3.
dbunit是一个基于junit扩展的数据库测试框架。它提供了大量的类对与数据库相关的操作进行了抽象和封装,虽然在80%的情况,你只需使用它极少的api。它通过使用用户自定义的数据集以及相关操作使数据库处于一种可知的状态,从而使得测试自动化、可重复和相对独立。虽然不用dbunit也可以达到这种目的,但是我们必须为此付出代价(编写大量代码,测试及维护),既然有了这么优秀的开源框架,我们又何必再造轮子。
dbunit的原理
dbunit的与单元测试相关的两个最重要的核心是org.dbunit.database.IDatabaseConnection 和 org.dbunit.dataset.IDataSet ,前者是产品代码使用的数据库连接的一个简单的封装,后者是对单元测试人员自定义的数据集(通常以xml文件的形式存在,且xml文件的格式也有好几种)的封装。
还有一个很重要的咚咚就是org.dbunit.operation.DatabaseOperation,该类是一个抽象类代表了对数据库的操作,例如CUD以及其组合等, 它采用了退化的工厂模式,可直接通过它获取其具体的子类(代表具体的某种操作)如下:
DatabaseOperation.UPDATE
DatabaseOperation.DELETE
DatabaseOperation.DELETE_ALL
DatabaseOperation.TRUNCATE
DatabaseOperation.REFRESH
DatabaseOperation.CLEAN_INSERT
DatabaseOperation.NONE
工作流程如下:
1)testcase.setup--->testcase.getConnection-->getDataSet----->operation.execute(
通常DatabaseOperation.CLEAN_INSERT)
2)testcase.testSomeMethod---->dao.someMethod
3)testcase.teardown---->operation.execute(
通常DatabaseOperation.DELETE_ALL或者DatabaseOperation.NONE)
通过与以前的例子比较发现:使用dbunit的testcase更自动化和可重复,以前写的testcase与数据库中的数据严重耦合,所以一般都不敢写断言,写了之后怕数据又发生变化,所以测试也是不可重复,并且也不是自动化,因为没有断言,你不得不测试完之后还得检查数据库。
当然dbunit也许并不是银弹,它在并发测试的时候得表现我没有实践过,也不敢妄下断言,而且是不是应该另外再建一个同样的数据专门测试dao还值得思考.
我们在项目中为每个开发人员自建一个数据库解决并发问题,也许这个方案并非最佳,但实用.

1690

被折叠的 条评论
为什么被折叠?



