junit4的一些高级用法（异常测试、参数化测试、以及对junit4的一些看法值得学习等）

以下内容选自http://www.blogjava.net/jnbzwm/archive/2010/12/15/340801.html。

由于原文格式太乱，故此只摘录对自己有用的黏贴在下面：

 

浅谈TDD

测试驱动开发，它是敏捷开发的最重要的部分。方法主要是先根据客户的需求编写测试程序，然后再编码使其通过测试。在敏捷开发实施中，开发人员主要从两个方面去理解测试驱动开发。

a)在测试的辅助下，快速实现客户需求的功能。通过编写测试用例，对客户需求的功能进行分解，并进行系统设计。我们发现从使用角度对代码的设计通常更符合后期开发的需求。可测试的要求，对代码的内聚性的提高和复用都非常有益。 
b)在测试的保护下，不断重构代码，提高代码的重用性，从而提高软件产品的质量。可见测试驱动开发实施的好坏确实极大的影响软件产品的质量，贯穿了软件开发的始终。 
在测试驱动开发中，为了保证测试的稳定性，被测代码接口的稳定性是非常重要的。否则，变化的成本就会急剧的上升。所以，自动化测试将会要求您的设计依赖于接口，而不是具体的类。进而推动设计人员重视接口的设计，体现系统的可扩展性和抗变性。 

 

使用注解而不是继承自TestCase的好处是：
a)允许我们遵循最适合的应用程序的命名约定；不再需要将所有的方法命名为 testAddition()、testXXX()的形式等等。
我们可以将测试方法使用与被测试的类相同的名称(由开发组规范约定)。例如，LoginAction.login() 由 LoginActionTest.login()方法测试、LoginAction.check()由LoginActionTest.check()方法测试等等。
b)使用JUnit4后，测试用例类可以不继承TestCase类，所以我们也就可以扩展被测试类了。
这种方法使得测试受保护的方法非常容易，我们只要将测试用例类继承被测试类，就可以测试受保护方法了。 

 

@BeforeClass和@AfterClass

这个特性虽然很好，但是一定要小心对待这个特性。它有可能会违反测试的独立性，并引入非预期的混乱。如果一个测试在某种程度上改变了 @BeforeClass 所初始化的一个对象，那么它有可能会影响其他测试的结果。也就是说，由BeforeClass申请或创建的资源，如果是整个测试用例类共享的，那么尽量不要让其中任何一个测试方法改变那些共享的资源，这样可能对其他测试方法有影响。它有可能在测试套件中引入顺序依赖，并隐藏 bug。

 

参数化测试

为了保证单元测试的严谨性，我们经常要模拟很多种输入参数，来确定我们的功能代码是可以正常工作的，为此我们编写大量的单元测试方法。可是这些测试方法都是大同小异：代码结构都是相同的，不同的仅仅是测试数据和期望输出值。
JUnit4 的参数化测试方法给我们提供了更好的方法，将测试方法中相同的代码结构提取出来，提高代码的重用度，减少复制粘贴代码的痛苦。
例如下面的功能代码(格式化字符串，将驼峰规则的字符串以"_"分隔)：

public class WordDealUtil {
public static String wordFormat4DB(String name) {
if (name == null) {
return null;
}
Pattern p = Pattern.compile("[A-Z]");
Matcher m = p.matcher(name);
StringBuffer sb = new StringBuffer();
while (m.find()) {
if (m.start() != 0) {
m.appendReplacement(sb, ("_" + m.group()).toLowerCase());
}
}
return m.appendTail(sb).toString().toLowerCase();
}
}

没有使用参数化的测试用例代码： 

public class WordDealUtilTest {
/**
* 测试 null 时的处理情况
*/
@Test
public void wordFormat4DBNull() {
String target = null;
String result = WordDealUtil.wordFormat4DB(target);
assertNull(result);
}
/**
* 测试空字符串的处理情况
*/
@Test
public void wordFormat4DBEmpty() {
String target = "";
String result = WordDealUtil.wordFormat4DB(target);
assertEquals("", result);
}
/**
* 测试当首字母大写时的情况
*/
@Test
public void wordFormat4DBegin() {
String target = "EmployeeInfo";
String result = WordDealUtil.wordFormat4DB(target);
assertEquals("employee_info", result);
}
/**
* 测试当尾字母为大写时的情况
*/
@Test
public void wordFormat4DBEnd() {
String target = "employeeInfoA";
String result = WordDealUtil.wordFormat4DB(target);
assertEquals("employee_info_a", result);
}
/**
* 测试多个相连字母大写时的情况
*/
@Test
public void wordFormat4DBTogether() {
String target = "employeeAInfo";
String result = WordDealUtil.wordFormat4DB(target);
assertEquals("employee_a_info", result);
}
}

看以上测试用例代码，结构相似，只是输入值与期望输出不同而已，但我们要拷贝很多代码。
使用参数化的测试用例代码：

@SuppressWarnings("unchecked")
@RunWith(Parameterized.class)
public class WordDealUtilTestWithParam {
private String expected;
private String target;
@Parameters
public static Collection words() {
return Arrays.asList(new Object[][] {
{ "employee_info", "employeeInfo" },  // 测试一般的处理情况
{ null, null },                         // 测试 null 时的处理情况
{ "", "" },                             // 测试空字符串时的处理情况
{ "employee_info", "EmployeeInfo" },    // 测试当首字母大写时的情况
{ "employee_info_a", "employeeInfoA" }, // 测试当尾字母为大写时的情况
{ "employee_a_info", "employeeAInfo" }  // 测试多个相连字母大写时的情况
});
}
/**
* 参数化测试必须的构造函数
* @param expected     期望的测试结果，对应参数集中的第一个参数
* @param target     测试数据，对应参数集中的第二个参数
*/
public WordDealUtilTestWithParam(String expected, String target) {
this.expected = expected;
this.target = target;
}
/**
* 测试将 Java 对象名称到数据库名称的转换
*/
@Test
public void wordFormat4DB() {
Assert.assertEquals(expected, WordDealUtil.wordFormat4DB(target));
}
}

很明显，代码简单且很清晰了。在静态方法 words 中，我们使用二维数组来构建测试所需要的参数列表，其中每个数组中的元素的放置顺序并没有什么要求，只要和构造函数中的顺序保持一致就可以了。现在如果再增加一种测试情况，只需要在静态方法 words 中添加相应的数组即可，不再需要复制粘贴出一个新的方法出来了。
这种参数化的测试用例写法，很适用于一些共用的功能方法。

 

 

测试异常@Test(expected=XXXException.class)

异常测试是 JUnit4 中的最大改进。旧式的异常测试是在抛出异常的代码中放入 try 块，然后在 try 块的末尾加入一个 fail() 语句。
例如，该方法测试被零除抛出一个 ArithmeticException：

 

public void testDivisionByZero() {
try {
int n = 2 / 0;
fail("Divided by zero!");
}
catch (ArithmeticException success) {
assertNotNull(success.getMessage());
}
}

该方法不仅难看，而且写起来也繁琐。在 JUnit 4 中，我们现在可以编写抛出异常的代码，并使用注释来声明该异常是预期的：

   @Test(expected = BusinessException.class)
public void testExecuteNameEmpty() throws Exception {
BookList bListAction = new BookList();
bListAction.setName("");
bListAction.execute();
}

附被测试代码(如果输入name为empty，则抛出BusinessException，若name不为"liming"，则抛出MessageException异常): 

    @Override
public String execute() throws Exception {
if (StringUtils.isEmpty(name)) {
throw new BusinessException("~", "name cant't empty.");
}
if (!StringUtils.equals("liming", name.trim())) {
throw new MessageException(name + " have no limits.");
}
Map ret = serviceCall.call(JMockService.queryDtlInfo, null);
orderId = (String) ret.get("OrderId");
dataList = (List) ret.get("Data");
return SUCCESS;
}