優秀的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？你應該費力地明白這一點。顯然，這個數字不是隨便得來的，並且還要確保該變數的命名可以顯示它的值是如何得來的。

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

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