什么是单元测试呢？单元测试就是针对最小的功能单元编写测试代码。Java程序最小的功能单元是方法，因此，对Java程序进行单元测试就是针对单个Java方法的测试。

1.JUnit

JUnit是一个开源的Java语言的单元测试框架，专门针对Java设计，使用最广泛。JUnit是事实上的单元测试的标准框架，任何Java开发者都应当学习并使用JUnit编写单元测试。
使用JUnit编写单元测试的好处在于，我们可以非常简单地组织测试代码，并随时运行它们，JUnit就会给出成功的测试和失败的测试，还可以生成测试报告，不仅包含测试的成功率，还可以统计测试的代码覆盖率，即被测试的代码本身有多少经过了测试。对于高质量的代码来说，测试覆盖率应该在80%以上。
此外，几乎所有的IDE工具都集成了JUnit，这样我们就可以直接在IDE中编写并运行JUnit测试。JUnit目前最新版本是5。

1.单元测试的好处

单元测试可以确保单个方法按照正确预期运行，如果修改了某个方法的代码，只需确保其对应的单元测试通过，即可认为改动正确。此外，测试代码本身就可以作为示例代码，用来演示如何调用该方法。
使用JUnit进行单元测试，我们可以使用断言（Assertion）来测试期望结果，可以方便地组织和运行测试，并方便地查看测试结果。此外，JUnit既可以直接在IDE中运行，也可以方便地集成到Maven这些自动化工具中运行。
在编写单元测试的时候，我们要遵循一定的规范：
一是单元测试代码本身必须非常简单，能一下看明白，决不能再为测试代码编写测试；
二是每个单元测试应当互相独立，不依赖运行的顺序；
三是测试时不但要覆盖常用测试用例，还要特别注意测试边界条件，例如输入为0，null，空字符串””等情况。
JUnit是一个单元测试框架，专门用于运行我们编写的单元测试：
一个JUnit测试包含若干@Test方法，并使用Assertions进行断言，注意浮点数assertEquals()要指定delta。

2.Fixture

JUnit提供了编写测试前准备、测试后清理的固定代码，我们称之为Fixture。
总结出编写Fixture的套路如下：

  1. 对于实例变量，在@BeforeEach中初始化，在@AfterEach中清理，它们在各个@Test方法中互不影响，因为是不同的实例；
  2. 对于静态变量，在@BeforeAll中初始化，在@AfterAll中清理，它们在各个@Test方法中均是唯一实例，会影响各个@Test方法。

大多数情况下，使用@BeforeEach和@AfterEach就足够了。只有某些测试资源初始化耗费时间太长，以至于我们不得不尽量“复用”时才会用到@BeforeAll和@AfterAll。
最后，注意到每次运行一个@Test方法前，JUnit首先创建一个XxxTest实例，因此，每个@Test方法内部的成员变量都是独立的，不能也无法把成员变量的状态从一个@Test方法带到另一个@Test方法。
编写Fixture是指针对每个@Test方法，编写@BeforeEach方法用于初始化测试资源，编写@AfterEach用于清理测试资源；
必要时，可以编写@BeforeAll和@AfterAll，使用静态变量来初始化耗时的资源，并且在所有@Test方法的运行前后仅执行一次。

3.异常测试

JUnit提供assertThrows()来期望捕获一个指定的异常。第二个参数Executable封装了我们要执行的会产生异常的代码。当我们执行Factorial.fact(-1)时，必定抛出IllegalArgumentException。assertThrows()在捕获到指定异常时表示通过测试，未捕获到异常，或者捕获到的异常类型不对，均表示测试失败。
以前的写法：

  1. @Test
  2. void testNegative() {
  3.     assertThrows(IllegalArgumentException.class, new Executable() {
  4.         @Override
  5.         public void execute() throws Throwable {
  6.             Factorial.fact(-1);
  7.         }
  8.     });
  9. }

Java 8开始引入了函数式编程，所有单方法接口都可以简写如下：

  1. @Test
  2. void testNegative() {
  3.     assertThrows(IllegalArgumentException.class, () -> {
  4.         Factorial.fact(-1);
  5.     });
  6. }

测试异常可以使用assertThrows()，期待捕获到指定类型的异常；
对可能发生的每种类型的异常都必须进行测试。

4.条件测试

在运行测试的时候，有些时候，我们需要排出某些@Test方法，不要让它运行，这时，我们就可以给它标记一个@Disabled：

  1. @Disabled
  2. @Test
  3. void testBug101() {
  4.     // 这个测试不会运行
  5. }

5.参数化测试

参数化测试和普通测试稍微不同的地方在于，一个测试方法需要接收至少一个参数，然后，传入一组参数反复运行。
JUnit提供了一个@ParameterizedTest注解，用来进行参数化测试。
假设我们想对Math.abs()进行测试，先用一组正数进行测试：

  1. @ParameterizedTest
  2. @ValueSource(ints = { 0, 1, 5, 100 })
  3. void testAbs(int x) {
  4.     assertEquals(x, Math.abs(x));
  5. }

通过@MethodSource注解，它允许我们编写一个同名的静态方法来提供测试参数：

  1. @ParameterizedTest
  2. @MethodSource
  3. void testCapitalize(String input, String result) {
  4.     assertEquals(result, StringUtils.capitalize(input));
  5. }
  7. static List<Arguments> testCapitalize() {
  8.     return List.of( // arguments:
  9.             Arguments.arguments("abc", "Abc"), //
  10.             Arguments.arguments("APPLE", "Apple"), //
  11.             Arguments.arguments("gooD", "Good"));
  12. }

另一种传入测试参数的方法是使用@CsvSource，它的每一个字符串表示一行，一行包含的若干参数用,分隔，因此，上述测试又可以改写如下：

  1. @ParameterizedTest
  2. @CsvSource({ "abc, Abc", "APPLE, Apple", "gooD, Good" })
  3. void testCapitalize(String input, String result) {
  4.     assertEquals(result, StringUtils.capitalize(input));
  5. }

如果有成百上千的测试输入，那么，直接写@CsvSource就很不方便。这个时候，我们可以把测试数据提到一个独立的CSV文件中，然后标注上@CsvFileSource：

  1. @ParameterizedTest
  2. @CsvFileSource(resources = { "/test-capitalize.csv" })
  3. void testCapitalizeUsingCsvFile(String input, String result) {
  4.     assertEquals(result, StringUtils.capitalize(input));
  5. }

Unit只在classpath中查找指定的CSV文件，因此，test-capitalize.csv这个文件要放到test目录下，内容如下：

  1. apple, Apple
  2. HELLO, Hello
  3. JUnit, Junit
  4. reSource, Resource