對于Java世界中的開發(fā)人員而言， JUnit似乎是最受歡迎的測試工具 。 因此，難怪就此主題已經(jīng)寫了一些好書 。 但是，通過以顧問為生，我仍然經(jīng)常遇到程序員，他們至多對工具及其正確用法都不了解。

因此，我想到了寫幾篇介紹基本技術(shù)的文章的想法。 目的是提供一個(gè)合理的起點(diǎn)，但要避免令人生畏的信息泛濫xUnit測試模式¹ 。 相反，將在適當(dāng)時(shí)提供指向深入文章，書籍章節(jié)或不同意見的指針，以便進(jìn)一步閱讀。

盡管存在有關(guān)該主題的其他文章，但本微型系列文章中采用的方法可能適合幫助一兩個(gè)開發(fā)人員熟悉JUnit測試的世界-這將使工作值得。

何必呢？

編寫高質(zhì)量的軟件是一項(xiàng)艱巨的任務(wù)。 至于其他許多倡導(dǎo)敏捷方法的人，對我而言，進(jìn)行大規(guī)模的前期計(jì)劃并不可行。 但是，就所有這些方法而言，當(dāng)我們開始將JUnit與TDD一起使用時(shí)，我獲得了最大的進(jìn)步。 確實(shí)，實(shí)證研究似乎證實(shí)了我的看法，正如infoQ文章所述² ，這種做法可以提高質(zhì)量 。

但是，JUnit測試并不像看起來那樣瑣碎。 我們一開始犯的一個(gè)致命錯(cuò)誤是將測試班視為第二等公民。 逐漸地，我們意識到測試不僅僅是一個(gè)簡單的驗(yàn)證機(jī)，而且-如果編寫得不當(dāng)心，可能會給維護(hù)和進(jìn)步帶來麻煩³ 。

如今，我傾向于將測試用例更多地視為被測單元的隨附規(guī)范 。 與齒輪之類的工件的規(guī)格非常相似，它告訴質(zhì)量檢查人員該單元必須滿足哪些關(guān)鍵指標(biāo)。 但是由于軟件的性質(zhì)，只有開發(fā)人員才能編寫如此低級的規(guī)范。 這樣，自動化測試就成為有關(guān)單元預(yù)期行為的重要信息來源。 還有一個(gè)不像文檔那樣容易過時(shí)的…

入門

一千英里的旅程始于一步
老子

讓我們假設(shè)我們必須編寫一個(gè)簡單的數(shù)字范圍計(jì)數(shù)器，該計(jì)數(shù)器從給定值開始傳遞一定數(shù)量的連續(xù)整數(shù)。 遵循隨附規(guī)范的隱喻，我們可以從以下代碼開始：

public class NumberRangeCounterTest { }

測試類表達(dá)了開發(fā)單位NumberRangeCounter的意圖 ， Meszaros將其表示為被測系統(tǒng) （SUT）。 按照通用的命名模式，單元名稱由后綴Test補(bǔ)充。

一切都很好，但是急躁的人可能會想：下一步是什么？ 首先應(yīng)該測試什么？ 而且–無論如何我如何創(chuàng)建可執(zhí)行測試？

有多種方法可以合并JUnit。 如果您使用Eclipse Java IDE，則該庫已包含在內(nèi)。 只需將其添加到項(xiàng)目的構(gòu)建路徑中，這在本教程中就足夠了。 要獲得自己的副本，請參閱下載并安裝 ，有關(guān)maven集成的信息，請參見《 使用JUnit》 ；如果您碰巧需要OSGi捆綁軟件，請?jiān)谠率耻壍老螺d中查找。

通常，從Happy Path開始是個(gè)好主意， Happy Path是執(zhí)行的“正常”路徑，理想情況下是一般業(yè)務(wù)用例。 對于SUT NumberRangeCounter這可能是一個(gè)驗(yàn)證測試，以確保計(jì)數(shù)器在方法的后續(xù)調(diào)用中返回連續(xù)的數(shù)字，該方法仍必須定義。

可執(zhí)行的JUnit測試是一個(gè)公開的非靜態(tài)方法，該方法使用@Test進(jìn)行注釋，并且不帶任何參數(shù)。 總結(jié)所有這些信息，下一步可能是以下方法存根⁴ ：

public class NumberRangeCounterTest {@Testpublic void subsequentNumber() { } }

仍然不多，但實(shí)際上JUnit第一次運(yùn)行測試就足夠了。 可以從命令行或特定的UI啟動JUnit測試運(yùn)行，但是在本教程的范圍內(nèi)，我假定您具有可用的IDE集成。 在Eclipse中，結(jié)果看起來像這樣⁵ ：

綠色條表示測試運(yùn)行未發(fā)現(xiàn)任何問題。 這并不奇怪，因?yàn)槲覀冞€沒有測試任何東西。 但是請記住，我們已經(jīng)做了一些有用的考慮，可以幫助我們輕松地進(jìn)行第一個(gè)測試：

我們打算編寫一個(gè)NumberRangeCounter單元，該單元負(fù)責(zé)傳遞連續(xù)的整數(shù)值序列。 為了測試它，我們可以創(chuàng)建一個(gè)局部變量，該局部變量采用此類計(jì)數(shù)器的新實(shí)例。

@Testpublic void subsequentNumber() { NumberRangeCounter counter = new NumberRangeCounter();}

由于第一個(gè)測試應(yīng)該斷言NumberRangeCounter提供的數(shù)字是連續(xù)的整數(shù)值，表示5、6、7等，因此SUT可以使用提供這些值的方法。 此外，可以兩次調(diào)用此方法以提供最小的后續(xù)值集。

@Testpublic void subsequentNumber() { NumberRangeCounter counter = new NumberRangeCounter();int first = counter.next();int second = counter.next();}

到目前為止看起來很合理，但是如果second的值不是first的有效后繼，我們?nèi)绾未_保測試運(yùn)行被表示為失敗？ 為此，JUnit提供了org.junit.Assert類，該類提供了一組靜態(tài)方法來幫助開發(fā)人員編寫所謂的自檢測試。

帶有assert前綴的方法用于檢查特定條件，并在否定結(jié)果上拋出AssertionError 。 JUnit運(yùn)行時(shí)會拾取此類錯(cuò)誤，并在結(jié)果報(bào)告中將測試標(biāo)記為失敗。

2014年8月13日更新：使用org.junit.Assert只是一種可能。 JUnit還包括一個(gè)匹配器庫Hamcrest ，許多人認(rèn)為它是有關(guān)干凈代碼的更好解決方案。 我個(gè)人最喜歡名為AssertJ的第三方庫的語法。

我認(rèn)為Assert對于初學(xué)者來說可能更直觀，因此我為“ hello world”帖子選擇它。 由于對該決定的評論，我意識到至少在這一點(diǎn)上我不得不提到其他可能性。 我將在后續(xù)文章中詳細(xì)介紹Hamcrest和AssertJ的用法。

要斷言兩個(gè)值或?qū)ο笙嗟?#xff0c;可以使用Assert#assertEquals 。 由于在聲明方法調(diào)用中使用靜態(tài)導(dǎo)入是很常見的，因此subsequentNumber測試可以像這樣完成：

@Testpublic void subsequentNumber() { NumberRangeCounter counter = new NumberRangeCounter();int first = counter.next();int second = counter.next();assertEquals( first + 1, second );}

如您所見，測試指定了SUT的重要行為，甚至還不存在。 順便說一句，這也意味著測試類不再編譯！ 因此，下一步可能是創(chuàng)建我們部門的框架來解決此問題。

盡管本教程是關(guān)于JUnit而不是TDD的，但是我還是選擇了后者的方法，以強(qiáng)調(diào)干凈的JUnit測試用例所具有的規(guī)范字符。 這種方法將工作重點(diǎn)從單位的內(nèi)部轉(zhuǎn)移到其使用和較低級別的要求上。

如果您想了解有關(guān)TDD的更多信息，特別是用于實(shí)現(xiàn)單個(gè)單元的“紅色/綠色/重構(gòu)”口頭禪，可以讀一讀 Kent Beck的“ 示例驅(qū)動開發(fā)”或Lasse Koskela的“ 示例 驅(qū)動”一書。

下面的代碼片段顯示了NumberRangeCounter存根的外觀：

public class NumberRangeCounter {public int next() {return 0;} }

再次運(yùn)行測試，由于NumberRangeCounter#next()實(shí)現(xiàn)不足，現(xiàn)在導(dǎo)致出現(xiàn)紅條。 這樣可以確保通過無用的驗(yàn)證或類似方式不會偶然滿足該規(guī)范：

除紅色條外，執(zhí)行報(bào)告還顯示總共運(yùn)行了多少測試，哪些測試因錯(cuò)誤而終止以及有多少由于錯(cuò)誤的斷言而失敗。 每個(gè)錯(cuò)誤/失敗的堆棧跟蹤信息有助于在測試類中找到確切的位置。

AssertionError提供了一條解釋性消息，該消息顯示在故障跟蹤的第一行中。 錯(cuò)誤測試可能表示任意編程錯(cuò)誤，從而導(dǎo)致在測試的斷言語句之外引發(fā)Exception 。

請注意，JUnit遵循“ 全有或全無”原則。 這意味著，如果一個(gè)測試運(yùn)行涉及一個(gè)以上的測試（通常是這種情況），則單個(gè)測試的失敗將整個(gè)執(zhí)行標(biāo)記為紅色，表示失敗。

由于某個(gè)特定單元的實(shí)際實(shí)現(xiàn)與本文主題無關(guān)，因此請您自己提出一種創(chuàng)新的解決方案，以使我們的第一個(gè)測試再次通過！

結(jié)論

前面的部分介紹了JUnit測試的基本知識–如何編寫，執(zhí)行和評估它。 在這樣做的同時(shí)，我重視這樣的事實(shí)，即應(yīng)該使用人們可能想到的最高編碼標(biāo)準(zhǔn)來開發(fā)此類測試。 給出的示例希望平衡得足夠好，以提供易于理解的介紹而又不瑣碎。 改進(jìn)建議當(dāng)然受到高度贊賞。

Nutshell文章中的下一個(gè)JUnit將繼續(xù)該示例，并涵蓋測試用例的一般概念及其四個(gè)階段的測試結(jié)構(gòu)，請繼續(xù)關(guān)注。

不要誤會我的意思-我非常喜歡這本書，但是通用方法可能不是入門的最佳方法：xUnit測試模式， Gerard Meszaros ，2007年

其他研究在http://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment上列出，對實(shí)證研究的比較分析可在https://tuhat.halvi.helsinki.fi/portal/files/29553974/2014_01_swqd_author_version.pdf上找到。

另請參閱：保持測試整潔，干凈的代碼，第9章， Robert C. Martin， 2009年

關(guān)于如何命名測試方法的觀點(diǎn)存在分歧。 我已經(jīng)在正確獲取JUnit測試名稱中寫下了有關(guān)此主題的一些注意事項(xiàng)

有關(guān)如何在Eclipse中使用JUnit的更多信息，您可能想閱讀我的文章《 在Eclipse中有效使用JUnit》

翻譯自: https://www.javacodegeeks.com/2014/08/junit-in-a-nutshell-hello-world.html

總結(jié)

以上是生活随笔為你收集整理的简而言之，JUnit：Hello World的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。