原创 | TDD 工具集:JUnit、AssertJ 和 Mockito (十八) 编写测试 - 测试执行顺序\嵌套的测试
本文分享在编写测试中“测试执行顺序、嵌套的测试”两节内容的方法。
测试执行顺序
重要性:★★★☆☆
如果一个测试类中有多个测试方法,缺省情况下,虽然JUnit会根据一个内在的算法确定这些方法的执行顺序(为了支持“可重复构建”的目标),但是对用户来说,其顺序并不是明显的——测试方法的名称和在测试类中出现的顺序都不是排序的依据。
正常情况下测试类中的每一个测试方法都应该是独立的——它的执行与否以及测试结果都不应该依赖于其他测试方法的预先执行。一个测试方法不应该依赖另一个测试方法为它预设测试条件(例如订单CRUD测试中,查询订单测试不应该依赖于创建订单测试为它先在数据库中创建订单,而应该在自身的setup阶段向数据库中插入测试数据)。
但是有的时候,尤其是在集成测试中,因为要与外部系统如数据库等进行交互,测试类中的每个测试方法在setup阶段都要启动数据库并向其中插入数据,就会导致严重的性能问题。这个时候我们可以接受安排测试方法的执行顺序,例如在订单CRUD测试中,安排创建订单测试先执行,向数据库中插入一到多条订单数据,随后执行查询订单测试和修改订单测试,最后执行删除订单测试。
当需要访问外部基础设施(如数据库、消息中间件等等)或者采用PER_CLASS模式执行测试时,定义测试方法的执行顺序比较有意义。
为了定义测试执行顺序,你需要:
用
@TestMethodOrder
注解测试类或测试接口,指定一个MethodOrderer
接口的实现类。如果采用
MethodOrderer
是MethodOrderer.OrderAnnotation
类,在每个要排序的测试方法上添加@Order
注解。@Order
的值越小,方法越先执行。
下面的代码示例根据@Order
注解进行排序:
还可以根据方法名称的字母表顺序进行排序:
还可以通过将测试类注解为:
来让测试方法伪随机排序执行。不过通常而言这种方式没啥必要。
嵌套的测试
重要性:★★★☆☆
有时候一个测试类中的测试方法太多,有必要根据内聚性原则将它们分组。
可以在测试类的内部定义嵌套内类(不能是静态内类)并注解为@Nested
将测试进行分组。在顶层类和嵌套类中都可以定义测试方法和生命周期方法。
嵌套的层级数量没有限制。
如果测试生命周期是PER_METHOD的,嵌套类不允许定义@BeforeAll
和@AfterAll
生命周期方法。如果测试生命周期是PER_CLASS的,嵌套类中可以定义@BeforeAll
和@AfterAll
生命周期方法。
如果外层测试类中有定义@BeforeEach
和@AfterEach
生命周期方法,那么它们也会在嵌套类的每个测试方法前后执行一次。
示例代码如下:
执行测试结果显示如下,可见输出也是层级化的:
一种可行的组织测试代码的方式是:为每个被测试的产品类创建一个对应的测试类。在测试类内部,针对被测类的每个工作单元(一般是方法)分别创建一个注解为@Nested
的嵌套类,包含针对这个工作单元的所有测试。
这一节就讲到这里,下一节我们讲讲"编写测试中的依赖注入、测试接口以及重复测试"。
版权声明: 本文为 InfoQ 作者【编程道与术】的原创文章。
原文链接:【http://xie.infoq.cn/article/87b4a489578f270606387ca2d】。文章转载请联系作者。
评论