來自:碼農(nóng)網(wǎng) 譯文鏈接:http://www./article/good-java-test.html 英文原文:https:///articles/anatomy-of-a-good-java-test 翻譯作者:碼農(nóng)網(wǎng) – 小峰
作為測試驅(qū)動設(shè)計和開發(fā)的忠實粉絲,我相信創(chuàng)造良好的測試是我們作為Java開發(fā)人員可以做的最重要的事情之一。我們寫測試出于許多原因:
塑造系統(tǒng)的設(shè)計。我們知道輸入和輸出應(yīng)該是什么樣的,但是我們需要創(chuàng)建什么對象來做到這一點呢?代碼應(yīng)該塑造成什么樣的“形狀”?編寫測試可以讓我們知道應(yīng)該創(chuàng)建什么樣的代碼。 為了確保初始和持續(xù)的正確性。讓我們的應(yīng)用程序如期望地那樣運作并且始終如一地精確很重要。測試應(yīng)該竭力確保做到這一點。 文檔。測試是系統(tǒng)的文檔,因為它會說明它應(yīng)該做什么以及應(yīng)該怎么做。
那么“好的測試”到底是什么樣子的呢?

給測試命名
測試的名字至關(guān)重要,特別是從文檔角度來看的話。我們應(yīng)該能夠大聲讀出測試的名字就像一組需求一樣。事實上,有一個偉大的IntelliJ插件,叫Enso,它會將你的測試名轉(zhuǎn)變?yōu)榍『梦挥诿總€類旁邊的語句,這樣你就可以明明白白地看到你在做什么。
不要以“test”開始命名測試的名稱。這是來自于JUnit初期的后遺癥,當(dāng)需要它執(zhí)行的時候。你的Test類將在Test文件夾中,在一個最后有Test這個單詞的類中。會有一個@Test的注解。我們知道這是一個測試。
你也應(yīng)該避免以“should”或“will”開頭。這些都是干擾詞。既然你已經(jīng)為這個功能寫了一個測試,那我們就知道它“should或will”工作(如果不能工作的話,那我們知道我們需要修復(fù)它)。

將測試名稱當(dāng)作一個要求。 下面是一些例子
addingNumbersWillSumValuesTogether() explodesOnNegativeID() notifiesListenersOnUpdates()
不要害怕表達(dá)出來。如果你的測試名稱確實需要很長的一串單詞,那就這么做,只要它能清楚說明將發(fā)生什么事情。
測試代碼
測試將分為3個部分:設(shè)置,操作,斷言。
設(shè)置
對你的測試設(shè)置代碼應(yīng)該只與在測試中被斷言的值相關(guān)。如果你有多余的設(shè)置代碼,那就會搞不清楚它是什么,并且與測試不相關(guān)。
這可以通過多種方式實現(xiàn):
將通用設(shè)置移動到使用@Before注解的具體設(shè)置方法。 將重復(fù)的設(shè)置代碼移動到輔助方法 使用Maker來創(chuàng)建復(fù)雜的測試對象,并只設(shè)置測試中相關(guān)的值。 我重申一下:每個測試的設(shè)置部分應(yīng)該只有與最后被斷言的值相關(guān)的代碼。
不好的例子:
@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 results = bookstore.findByTitle('RY pot'); assertThat(results.size(), is(2)); assertThat(results, containsInAnyOrder(harryPotterOne, harryPotterTwo)); }
書店的初始化發(fā)生在測試中,書本的創(chuàng)建也是。這讓測試顯得混亂不堪,讓人搞不清楚發(fā)生了什么事情。
好的例子:
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 results = bookstore.findByTitle('RY pot'); assertThat(results.size(), is(2)); assertThat(results, containsInAnyOrder(aHarryPotterBook, anotherHarryPotterBook)); }
初始化發(fā)生在字段中,這樣在測試中發(fā)生了什么一清二楚。
操作
小菜一碟!最好保持到一行,你要進行測試的獨立操作。有時候,你專門測試的是輸出是什么,如果某些東西被多次調(diào)用,或者在某些優(yōu)先操作之后調(diào)用的結(jié)果是什么,所以這不是一個硬性規(guī)定。當(dāng)讀取測試時,用戶應(yīng)該快速而輕松地能說“將這些值設(shè)置成這樣,如果我執(zhí)行這個操作/這些操作,那么這是預(yù)期的結(jié)果”。在上面的例子中,便是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));
這些相當(dāng)簡單的例子:Hamcrest有很多偉大的方法,使編寫復(fù)雜測試變得很容易,并允許你創(chuàng)建自己的匹配器。
當(dāng)然,理想情況下,我們希望有一個獨立的斷言。這可以讓我們知道我們正在測試什么,并說明我們的代碼沒有意外情況。就像這篇文章中所說的那樣,這不是一個硬性的規(guī)則,因為在某些情況下,這是必要的,但如果你有這樣一個的測試:
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可為復(fù)雜斷言提供一個優(yōu)雅的解決方案。如果你需要在一個循環(huán)中運行斷言,或者你有大量的字段要斷言,那么一個自定義的匹配器可能才是上上之選。
一個測試的最重要的部分之一是,當(dāng)它失敗時,哪怕是一個5歲孩子也應(yīng)該看得出什么地方出了錯以及哪里錯了。失敗的消息一定不能含糊。關(guān)于這方面的解決方法是:
如果做任何類型的對象比較,那么保證對象有一個體面的toString()消息。沒有什么比不匹配更糟的了。
想要做的更好的話,可以對你的對象使用自定義匹配器。你可以準(zhǔn)確地知道哪些字段未能匹配。
確保明確為什么你要選擇和這個值作比較。例如,如果你正在將一個字段值與數(shù)字3000比較,那么為什么是3000?你應(yīng)該費力地明白這一點。顯然,這個數(shù)字不是隨便得來的,并且還要確保該變量的命名可以顯示它的值是如何得來的。
所有這些都應(yīng)該是在一個適度的常識范圍內(nèi)。沒有嚴(yán)格規(guī)定!
●本文編號88,以后想閱讀這篇文章直接輸入88即可。 ●輸入m可以獲取到文章目錄。
|