Junit 最佳实践

对还没有实现的测试代码抛出一个异常

这种做法可以防止测试通过并且提醒自己必须实现这部分代码.

如: @Test

public void testMethod(){

throw new RuntimeException("implements me");

}

一次只能单元测试一个对象

单元测试的一个至关重要的方面就是细粒度.一个单元测试独立的检查你创建的每一个对象,这样你就可以在问题发生的第一时间把它们隔离起来.如果被测试的对象多于一个,那么一旦这些对象发生了变化,你就无法预测它们将如何相互影响.当一个对象与其他复杂的对象交互时,你就可以使用可预测的测试对象将被测试的对象包围起来.

选择有意义的测试方法名字

一条好建议是测试方法的名字采用testXXX的命名模式,其中XXX是待测试领域方法的名字.当你需要为同一个方法添加其他测试时,则可以采用testXXXYYY的命名模式,其中YYY表示了测试之间的不同

在assert调用中解析失败原因

无论何时,只要你使用了JUnit的任何assertXXX方法,就要确保自己使用第一个参数为String类型的那个签名(如:assertNotNull("Must not return a null result",result)).这个参数让你可以提供一个用意义的文本描述,在断言失败时,JUnit的test runner就会显示这个描述.如果不使用这个参数,当测试失败时,要找出失败原因就会比较麻烦和困难了

一个单元测试等于一个@Test方法

为了获得最好的结果,你的测试方法应当尽量的简单明了和目的明确,不要试图把多个测试塞进一个方法.这样导致的结果就是测试方法变得更加复杂,难以阅读也难以理解,所谓理解万岁嘛.^_^,而且你在测试方法中编写的逻辑越多,测试失败的可能性就越高,甚至需要调试才能解决问题.这就会陷入一个滑坡,使得你很可能会堕入不得不为你的测试代码编写测试的深渊

始终使assert得到调用

当你测试的代码没有包含任何assert语句,执行测试时,JUnit会将它们标记为测试成功,但这只是一个自欺欺人的假象.记得要始终调用assert,唯一可以接受不实用assert调用的情况是当抛出一个异常来指出一个错误条件时.

迫使错误条件发生是测试灾难恢复能力的极佳做法

测试任何可能失败的事物

如果一个方法被改变了,变得不再简单,那么当发生这个改变时,你就应当为这个方法添加一个测试,但在改变之前方法简单得不会出错则不需要增加.

未完,待续...