作為測試驅動設計和開發的忠實粉絲，我相信創造良好的測試是我們作為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？你應該費力地明白這一點。顯然，這個數字不是隨便得來的，並且還要確保該變量的命名可以顯示它的值是如何得來的。
所有這些都應該是在一個適度的常識范圍內。沒有嚴格規定！
歡迎加入學習交流群569772982，大家一起學習交流。