上周我们刚刚搭建好了 JUnit 5 的环境，现在我们可以写测试了。这节让我们来写它几个吧！
概述
本文章是这个 JUnit 5 系列的一部分：
· 环境搭建
· 基础入门
· 架构体系
· 扩展模型(Extension Model)
· 条件断言
· 注入
· 动态测试
...
(如果不喜欢看文章，你可以戳这里看我的演讲，或者看一下近的 vJUG 讲座，或者我在 DevoxxPL 上的 PPT。
本系列文章都基于 Junit 5发布的先行版 Milestone 2。它可能会有变化。如果有新的里程碑(milestone)版本发布，或者试用版正式发行时，我会再来更新这篇文章。
这里要介绍的多数知识你都可以在 JUnit 5 用户指南 中找到(这个链接指向的是先行版 Milestone 2，想看的新版本文档的话请戳这里)，并且指南还有更多的内容等待你发掘。下面的所有代码都可以在 我的 Github 上找到。
设计哲学
新的架构设计(这个我们日后聊)，其关注点在高扩展性。如果后面出现了什么神之测试技术(至少对我们广大 Java?来说很神的)，它们也可能在 JUnit 5 的架构下被实现。
不过当前来说，涉及的基础知识与 JUnit 4 是非常相似的。JUnit 5 的改动并不激进，相反它的优化历程是小心翼翼，小步迭代的。因此，开发者应该会对新的 API 感到非常熟悉。至少我是这样的，我相信你也不会感觉陌生：
class Lifecycle {
@BeforeAll
static void initializeExternalResources() {
System.out.println("Initializing external resources...");
}
@BeforeEach
void initializeMockObjects() {
System.out.println("Initializing mock objects...");
}
@Test
void someTest() {
System.out.println("Running some test...");
assertTrue(true);
}
@Test
void otherTest() {
assumeTrue(true);
System.out.println("Running another test...");
assertNotEquals(1， 42， "Why wouldn't these be the same?");
}
@Test
@Disabled
void disabledTest() {
System.exit(1);
}
@AfterEach
void tearDown() {
System.out.println("Tearing down...");
}
@AfterAll
static void freeExternalResources() {
System.out.println("Freeing external resources...");
}
}
是吧?这里并没有很大的改动。
JUnit 5 预备
包可见性
JUnit 5 明显的变化应该是，不再需要手动将测试类与测试方法为 public 了。包可见的访问级别足够了。当然，私有(private)访问还是不行的。我认为这个变化是合理的，也符合我们对可见性的一般直觉。
这很好!至少可以少打几个字母了。不过，我相信你也不是每次都手打这几个字母的，是吧?尽管如此还是很好，少一些关键字，你在看测试的时候也少些切换。
测试的生命周期
@Test
JUnit 中基本的注解非 @Test 莫属了。它会标记方法为测试方法，以便构建工具和 IDE 能够识别并执行它们。
它的 API 和作用并没有变化，不过它不再接受任何参数了。若要测试是否抛出异常，你可以通过新的断言 API 来做到;不过我所知，目前还没有超时选项timeout的替代品。
与 JUnit 4一样，JUnit 5 会为每个测试方法创建一个新的实例。
Before 和 After
你可能需要执行一些代码来在测试执行前后完成一些初始化或销毁的操作。在 JUnit 5 中，有4个注解你可能会用于如此工作：
@BeforeAll
只执行一次，执行时机是在所有测试和 @BeforeEach 注解方法之前。
@BeforeEach
在每个测试执行之前执行。
@AfterEach
在每个测试执行之后执行。
@AfterAll
只执行一次，执行时机是在所有测试和 @AfterEach 注解方法之后。
因为框架会为每个测试创建一个单独的实例，在 @BeforeAll/@AfterAll 方法执行时尚无任何测试实例诞生。因此，这两个方法必须定义为静态方法。
注解了同样一个注解的不同方法，其执行次序是不可预知的，包括对继承来的方法也适用。这是开发团队经过审慎思考后的决定，即把单元测试与集成测试的关注点分开。集成测试可能需要方法间更紧密的协作，但一个单元测试不应该对其他的单元测试有所依赖。而对于集成测试——也叫场景测试——的支持，也已在团队的计划中。
除了名字有所不同，这几个注解与 JUnit 4 中的注解工作方式完全一样。无独有偶，跟主流意见一致，我也觉得这个新的命名不能说服我其必要性。这个 issue 下有更多的讨论。
禁用测试
今儿星期五，抬头一看已经4点半，无心工作的你想回家了?完全理解，在测试上怒拍一个 @Disabled 注解即可。有良心的话写个忽略测试的理由是极好的，不过也可以不带此参数。
@Test
@Disabled("你丫是存心跑不过的是不？！")
void failingTest() {
assertTrue(false);
}
测试类的生命周期
JUnit 团队发布的第一版原型中，包含了一个对 测试类的生命周期 的描述，有意思的是，这个特性在 alpha 版本的发布中未被加入。这个生命周期模型建议，在被测类的多个测试方法中使用一个同样的实例，因为这样我们可以通过改变对象的状态，进而实现在多个测试方法中的交互。(我也再说一遍，这更像是 场景测试 要管的事。)
正如我在第一版公测时所说，这样的特性99%的场景下是有害的，只有另外1%的场合下才有真正的用处。我只能说，还好这个特性被摒弃了。想想你的单元测试，如果它们必须靠在方法间维护状态来工作，这画面简直太美我不敢看?。
断言
如果说 @Test、@Before...、@After... 等注解是一个测试套件的骨架，那么断言是它的心脏。准备好测试实例、执行了被测类的方法以后，断言能确保你得到了想要的结果。否则，说明当前测试失败了。
常规断言
一般的断言，无非是检查一个实例的属性(比如，判空与判非空等)，或者对两个实例进行比较(比如，检查两个实例对象是否相等)等。无论哪种检查，断言方法都可以接受一个字符串作为后一个可选参数，它会在断言失败时提供必要的描述信息。如果提供出错信息的过程比较复杂，它也可以被包装在一个 lambda 表达式中，这样，只有到真正失败的时候，消息才会真正被构造出来。
@Test
void assertWithBoolean() {
assertTrue(true);
assertTrue(this::truism);
assertFalse(false， () -> "Really " + "expensive " + "message" + ".");
}
boolean truism() {
return true;
}
@Test
void assertWithComparison() {
List<String> expected = asList("element");
List<String> actual = new LinkedList<>(expected);
assertEquals(expected， actual);
assertEquals(expected， actual， "Should be equal.");
assertEquals(expected， actual， () -> "Should " + "be " + "equal.");
assertNotSame(expected， actual， "Obviously not the same instance.");
}
如你所见，JUnit 5 的 API 并无太多变化。断言方法的命名是一样的，方法同样接受两个参数，分别是一个期望值与一个实际值。
期望值与实际值的传入顺序非常重要，无论是对于理解测试的内容，还是理解失败时的错误信息，但有时还是很容易弄错，这点很坑。不过仔细想想，也没什么更好的办法，除非你自己创建一个新的断言框架。既然市面上已有对应的产品如 Hamcrest (ugh!) 和AssertJ (yeah!译者表示：不太清楚这欢呼的梗在哪里)等，再浪费有限的时间去造轮子明显不值得。毕竟重要的是保证你的断言库专注于一件事，借鉴已有实现可以节省成本。
哦对了，失败信息现在是作为后传入的参数了。我很喜欢这个细节，因为，它让你专注于真正重要之事——那两个需被断言的值。由于拥抱了 Java 8 的缘故，真值断言方法现在也接受 supplier 参数了，又是一个暖心的小细节。
扩展断言
除了那种一般的检查特定实例或属性的断言外，还有一些其他类型的断言。
这里要讲的第一个甚至都不是个真正的断言，它做的事是强行让测试失败，并提供一个失败信息。
@Test
void failTheTest() {
fail("epicly");
}
