摘要：中常用的單元測試工具是老牌測試框架了，也是目前引用最廣泛的一個框架?？梢允褂眠m當(dāng)?shù)膯卧獪y試方式，比如可以提供一個測試接口，利用的熱部署功能實現(xiàn)不重啟及時修改代碼。

單元測試（英語：Unit Testing）又稱為模塊測試, 是針對程序模塊（軟件設(shè)計的最小單位）來進(jìn)行正確性檢驗的測試工作。程序單元是應(yīng)用的最小可測試部件。在過程化編程中，一個單元就是單個程序、函數(shù)、過程等；對于面向?qū)ο缶幊蹋钚卧褪欠椒?，包括基類（超類）、抽象類、或者派生類（子類）中的方法?br>通常來說，程序員每修改一次程序就會進(jìn)行最少一次單元測試，在編寫程序的過程中前后很可能要進(jìn)行多次單元測試，以證實程序達(dá)到軟件規(guī)格書要求的工作目標(biāo)，沒有程序錯誤；雖然單元測試不是什么必須的，但也不壞，這牽涉到項目管理的政策決定。

優(yōu)質(zhì)的單元測試可以保障開發(fā)質(zhì)量和程序的魯棒性。在大多數(shù)互聯(lián)網(wǎng)企業(yè)中開發(fā)工程師在研發(fā)過程中都會頻繁地執(zhí)行測試用例，運行失敗的單測能幫助我們快速排查和定位問題 使問題在被帶到線上之前完成修復(fù)。正如軟件工程界的一條金科玉律----越早發(fā)現(xiàn)的缺陷，其修復(fù)成本越低。一流的測試能發(fā)現(xiàn)未發(fā)生的故障；二流的測試能快速定位故障的發(fā)生點；三流的測試則疲于奔命，一直跟在故障后面進(jìn)行功能回歸。

https://junit.org/junit5/

junit是老牌測試框架了，也是目前引用最廣泛的一個框架。當(dāng)前已經(jīng)更新到Junit5，功能更強大。

class StandardTests {

    @BeforeAll
    static void initAll() {
    }

    @BeforeEach
    void init() {
    }

    @Test
    void succeedingTest() {
    }

    @Test
    void failingTest() {
        fail("a failing test");
    }

    @Test
    @Disabled("for demonstration purposes")
    void skippedTest() {
        // not executed
    }

    @Test
    void abortedTest() {
        assumeTrue("abc".contains("Z"));
        fail("test should have been aborted");
    }

    @AfterEach
    void tearDown() {
    }

    @AfterAll
    static void tearDownAll() {
    }

}

https://assertj.github.io/doc/

一個功能強悍的斷言工具，支持各種斷言方式

// entry point for all assertThat methods and utility methods (e.g. entry)
import static org.assertj.core.api.Assertions.*;

// basic assertions
assertThat(frodo.getName()).isEqualTo("Frodo");
assertThat(frodo).isNotEqualTo(sauron);

// chaining string specific assertions
assertThat(frodo.getName()).startsWith("Fro")
                           .endsWith("do")
                           .isEqualToIgnoringCase("frodo");

// collection specific assertions (there are plenty more)
// in the examples below fellowshipOfTheRing is a List
assertThat(fellowshipOfTheRing).hasSize(9)
                               .contains(frodo, sam)
                               .doesNotContain(sauron);

// as() is used to describe the test and will be shown before the error message
assertThat(frodo.getAge()).as("check %s"s age", frodo.getName()).isEqualTo(33);

// Java 8 exception assertion, standard style ...
assertThatThrownBy(() -> { throw new Exception("boom!"); }).hasMessage("boom!");
// ... or BDD style
Throwable thrown = catchThrowable(() -> { throw new Exception("boom!"); });
assertThat(thrown).hasMessageContaining("boom");

// using the "extracting" feature to check fellowshipOfTheRing character"s names (Java 7)
assertThat(fellowshipOfTheRing).extracting("name")
                               .contains("Boromir", "Gandalf", "Frodo", "Legolas")
// same thing using a Java 8 method reference
assertThat(fellowshipOfTheRing).extracting(TolkienCharacter::getName)
                               .doesNotContain("Sauron", "Elrond");

// extracting multiple values at once grouped in tuples (Java 7)
assertThat(fellowshipOfTheRing).extracting("name", "age", "race.name")
                               .contains(tuple("Boromir", 37, "Man"),
                                         tuple("Sam", 38, "Hobbit"),
                                         tuple("Legolas", 1000, "Elf"));

// filtering a collection before asserting in Java 7 ... 
assertThat(fellowshipOfTheRing).filteredOn("race", HOBBIT)
                               .containsOnly(sam, frodo, pippin, merry);
// ... or in Java 8
assertThat(fellowshipOfTheRing).filteredOn(character -> character.getName().contains("o"))
                               .containsOnly(aragorn, frodo, legolas, boromir);

// combining filtering and extraction (yes we can)
assertThat(fellowshipOfTheRing).filteredOn(character -> character.getName().contains("o"))
                               .containsOnly(aragorn, frodo, legolas, boromir)
                               .extracting(character -> character.getRace().getName())
                               .contains("Hobbit", "Elf", "Man");

// and many more assertions: iterable, stream, array, map, dates (java 7 and 8), path, file, numbers, predicate, optional ...

https://site.mockito.org/

一個單元測試中的Mock工具，可以很靈活的創(chuàng)建對象，配合單元測試。

// You can mock concrete classes and interfaces
TrainSeats seats = mock(TrainSeats.class);

// stubbing appears before the actual execution
when(seats.book(Seat.near(WINDOW).in(FIRST_CLASS))).thenReturn(BOOKED);

// the following prints "BOOKED"
System.out.println(seats.book(Seat.near(WINDOW).in(FIRST_CLASS)));

// the following prints "null" because 
// .book(Seat.near(AISLE).in(FIRST_CLASS))) was not stubbed
System.out.println(seats.book(Seat.near(AISLE).in(FIRST_CLASS)));

// the following verification passes because 
// .book(Seat.near(WINDOW).in(FIRST_CLASS)) has been invoked
verify(seats).book(Seat.near(WINDOW).in(FIRST_CLASS));

// the following verification fails because 
// .book(Seat.in(SECOND_CLASS)) has not been invoked
verify(seats).book(Seat.in(SECOND_CLASS));

對于業(yè)務(wù)代碼，有時單元測試并不方便，因為每次啟動成本過高?？梢允褂眠m當(dāng)?shù)膯卧獪y試方式，比如可以提供一個測試接口，利用IDE的熱部署功能實現(xiàn)不重啟及時修改代碼。

但是對于非業(yè)務(wù)性代碼，進(jìn)行單元測試時非常有必要的，可以更早的發(fā)現(xiàn)代碼中的問題，同時也可以檢驗程序的解耦性。

良好的代碼設(shè)計在單元測試時會更方便，反之緊耦合的設(shè)計會給單元測試帶來很大的困擾。