優秀的Java程序測試是什麼樣的？

　　作為測試驅動設計和開發的忠實粉絲，我相信創造良好的測試是我們作為 Java 開發人員可以做的最重要的事情之一。我們寫測試出於許多原因：

• 塑造系統的設計。我們知道輸入和輸出應該是什麼樣的，但是我們需要創建什麼對象來做到這一點呢？代碼應該塑造成什麼樣的“形狀”？編寫測試可以讓我們知道應該創建什麼樣的代碼。
• 為了確保初始和持續的正確性。讓我們的應用程序如期望地那樣運作並且始終如一地精確很重要。測試應該竭力確保做到這一點。
• 文檔。測試是系統的文檔，因為它會說明它應該做什麼以及應該怎麼做。

　　那麼“好的測試”到底是什麼樣子的呢？

　　給測試命名

　　測試的名字至關重要，特別是從文檔角度來看的話。我們應該能夠大聲讀出測試的名字就像一組需求一樣。事實上，有一個偉大的 IntelliJ 插件，叫 Enso，它會將你的測試名轉變為恰好位於每個類旁邊的語句，這樣你就可以明明白白地看到你在做什麼。

　　不要以“test”開始命名測試的名稱。這是來自於 JUnit 初期的後遺症，當需要它執行的時候。你的 Test 類將在 Test 文件夾中，在一個最後有 Test 這個單詞的類中。會有一個@Test 的注解。我們知道這是一個測試。

　　你也應該避免以“should”或“will”開頭。這些都是干擾詞。既然你已經為這個功能寫了一個測試，那我們就知道它“should 或 will”工作（如果不能工作的話，那我們知道我們需要修復它）。

　　將測試名稱當作一個要求。 下面是一些例子

addingNumbersWillSumValuesTogether ()
explodesOnNegativeID ()
notifiesListenersOnUpdates ()

　　不要害怕表達出來。如果你的測試名稱確實需要很長的一串單詞，那就這麼做，只要它能清楚說明將發生什麼事情。

　　測試代碼

　　測試將分為 3 個部分：設置，操作，斷言。

　　設置

　　對你的測試設置代碼應該只與在測試中被斷言的值相關。如果你有多余的設置代碼，那就會搞不清楚它是什麼，並且與測試不相關。

　　這可以通過多種方式實現：

• 將通用設置移動到使用@Before 注解的具體設置方法。
• 將重復的設置代碼移動到輔助方法
• 使用 Maker 來創建復雜的測試對象，並只設置測試中相關的值。

　　我重申一下：每個測試的設置部分應該只有與最後被斷言的值相關的代碼。

　　不好的例子：

@Test
    public void returnsBooksWherePartialTitleMatchesInAnyCast (){
        Bookstore bookstore = new Bookstore ();
        Book harryPotterOne = new Book ("Harry Potter and The Philosopher Stone");
        bookstore.add (harryPotterOne);
        bookstore.add (new Book ("Guardians of the Galaxy"));
        Book harryPotterTwo = new Book ("The Truth about HARRY POTTER");
        bookstore.add (harryPotterTwo);
        List<Book> results = bookstore.findByTitle ("RY pot");
        assertThat (results.size (), is(2));
        assertThat (results, containsInAnyOrder (harryPotterOne, harryPotterTwo));
    }

　　書店的初始化發生在測試中，書本的創建也是。這讓測試顯得混亂不堪，讓人搞不清楚發生了什麼事情。

　　好的例子：

private Bookstore bookstore = new Bookstore ();
private Book aHarryPotterBook = new Book ("Harry Potter and The Philosopher Stone");
private Book anotherHarryPotterBook = new Book ("The Truth about HARRY POTTER");
private Book aBook = new Book ("Guardians of the Galaxy");
@Test
public void returnsBooksWherePartialTitleMatchesInAnyCast (){
    bookstore.add (aHarryPotterBook);
    bookstore.add (aBook);
    bookstore.add (anotherHarryPotterBook);
    List<Book> results = bookstore.findByTitle ("RY pot");
    assertThat (results.size (), is(2));
    assertThat (results, containsInAnyOrder (aHarryPotterBook, anotherHarryPotterBook));
}

　　初始化發生在字段中，這樣在測試中發生了什麼一清二楚。

　　操作

　　小菜一碟！最好保持到一行，你要進行測試的獨立操作。有時候，你專門測試的是輸出是什麼，如果某些東西被多次調用，或者在某些優先操作之後調用的結果是什麼，所以這不是一個硬性規定。當讀取測試時，用戶應該快速而輕松地能說“將這些值設置成這樣，如果我執行這個操作/這些操作，那麼這是預期的結果”。在上面的例子中，便是 bookstore.findByTitle ()方法。

　　斷言

　　使用 Hamcrest。 Hamcrest 是一個很棒的庫，給我們一個流暢的 API 用來寫入測試。不會像這樣的代碼：

assertEquals (results.size (), 2);
assertTrue (results.contains (aHarryPotterBook))
assertTrue (results.contains (anotherHarryPotterBook))

　　我們可以一目了然、輕松地閱讀像這樣的代碼：

assertThat (results.size (), is(2));
assertThat (results, containsInAnyOrder (aHarryPotterBook, anotherHarryPotterBook));

　　這些相當簡單的例子：Hamcrest 有很多偉大的方法，使編寫復雜測試變得很容易，並允許你創建自己的匹配器。

　　當然，理想情況下，我們希望有一個獨立的斷言。這可以讓我們知道我們正在測試什麼，並說明我們的代碼沒有意外情況。就像這篇文章中所說的那樣，這不是一個硬性的規則，因為在某些情況下，這是必要的，但如果你有這樣一個的測試：

assertThat (orderBook.bids.size (), is(4));
assertThat (orderBook.asks.size (), is(3));
assertThat (orderBook.bids.get(0) .price, is(5200));
assertThat (orderBook.asks.get(2) .price, is(10000000));
assertThat (orderBook.asks.get(2) .isBuy, is(false));

　　那麼要理解測試哪裡失敗或哪條斷言重要就變得困難多了。

　　你也可以在 Hamcrest 中編寫自定義的匹配器，因為 Hamcrest 可為復雜斷言提供一個優雅的解決方案。如果你需要在一個循環中運行斷言，或者你有大量的字段要斷言，那麼一個自定義的匹配器可能才是上上之選。

　　一個測試的最重要的部分之一是，當它失敗時，哪怕是一個 5 歲孩子也應該看得出什麼地方出了錯以及哪裡錯了。失敗的消息一定不能含糊。關於這方面的解決方法是：

• 如果做任何類型的對象比較，那麼保證對象有一個體面的 toString（）消息。沒有什麼比<MyObject @ 142131>不匹配更糟的了。
• 想要做的更好的話，可以對你的對象使用自定義匹配器。你可以准確地知道哪些字段未能匹配。
• 確保明確為什麼你要選擇和這個值作比較。例如，如果你正在將一個字段值與數字 3000 比較，那麼為什麼是 3000？你應該費力地明白這一點。顯然，這個數字不是隨便得來的，並且還要確保該變量的命名可以顯示它的值是如何得來的。

　　所有這些都應該是在一個適度的常識范圍內。沒有嚴格規定！

　　你還有什麼要補充的嗎？歡迎告訴我們。

　　英文原文：Anatomy of a Good Java Test