junit:junit_简而言之，JUnit：Hello World
junit:junit
對于Java世界中的開發人員而言， JUnit似乎是最受歡迎的測試工具 。 因此，難怪就此主題已經寫了一些好書 。 但是，通過以顧問為生，我仍然經常遇到程序員，他們至多對工具及其正確用法都不了解。
因此，我想到了寫幾篇介紹基本技術的文章的想法。 目的是提供一個合理的起點，但要避免xUnit測試模式1帶來的艱巨信息泛濫。 相反，將在適當時提供指向深入文章，書籍章節或不同意見的指針，以供進一步閱讀。
盡管存在有關該主題的其他文章，但本微型系列文章中采用的方法可能適合于幫助一兩個開發人員熟悉JUnit測試的世界-這將使工作值得。
何必呢？
編寫高質量的軟件是一項艱巨的任務。 至于許多其他倡導敏捷方法的人，對我而言，進行大規模的前期計劃并不是一件好事。 但是對于所有這些方法，當我們開始將JUnit與TDD一起使用時，我獲得了最大的進步。 確實，實證研究似乎證實了我的看法，即infoQ文章指出2這種做法可以提高質量 。
但是，JUnit測試并不像看起來那樣瑣碎。 我們一開始犯的一個致命錯誤是將測試班視為二等公民。 逐漸地，我們意識到測試不僅僅是一個簡單的驗證機，而且-如果編寫得不當心，可能會給維護和進步帶來麻煩3 。
如今，我傾向于將測試用例更多地視為被測單元的隨附規范 。 與齒輪之類的工件的規格非常相似，它告訴質量檢查人員該單元必須滿足哪些關鍵指標。 但是由于軟件的性質，只有開發人員才能編寫如此低級的規范。 這樣，自動化測試就成為有關單元預期行為的重要信息來源。 還有一個不像文檔那樣容易過時的…
入門
一千英里的旅程始于一步
老子
讓我們假設我們必須編寫一個簡單的數字范圍計數器，該計數器從給定值開始傳遞一定數量的連續整數。 遵循隨附規范的隱喻，我們可以從以下代碼開始：
public class NumberRangeCounterTest { }測試類表達了開發單位NumberRangeCounter的意圖 ， Meszaros將其表示為被測系統 （SUT）。 按照通用的命名模式，單元名稱由后綴Test補充。
一切都很好，但是急躁的人可能會想：下一步是什么？ 首先應該測試什么？ 而且–無論如何我如何創建可執行測試？
有多種方法可以合并JUnit。 如果使用Eclipse Java IDE，則該庫已包含在內。 只需將其添加到項目的構建路徑中，這在本教程中就足夠了。 要獲得自己的副本，請參閱下載并安裝 ，有關maven集成的信息，請參見《 使用JUnit》 ；如果您碰巧需要OSGi捆綁軟件，請在蝕軌道下載中查找。
通常，從Happy Path開始是個好主意， Happy Path是執行的“正常”路徑，理想情況下是一般業務用例。 對于SUT NumberRangeCounter這可能是一個驗證測試，以確保計數器在方法的后續調用中返回連續的數字，該方法仍必須定義。
可執行的JUnit測試是一個公開的非靜態方法，該方法使用@Test進行注釋，并且不帶任何參數。 總結所有這些信息，下一步可能是以下方法存根4 ：
public class NumberRangeCounterTest {@Testpublic void subsequentNumber() { } }仍然不多，但實際上JUnit第一次運行測試就足夠了。 可以從命令行或特定的UI啟動JUnit測試運行，但是在本教程的范圍內，我假定您具有可用的IDE集成。 在Eclipse中，結果看起來像這樣5 ：
綠色條表示測試運行未發現任何問題。 這并不奇怪，因為我們尚未進行任何測試。 但是請記住，我們已經做了一些有用的考慮，可以幫助我們輕松地進行第一個測試：
到目前為止看起來很合理，但是如果second的值不是first的有效后繼，我們如何確保測試運行被表示為失敗？ 為此，JUnit提供了org.junit.Assert類，該類提供了一組靜態方法來幫助開發人員編寫所謂的自檢測試。
帶有assert前綴的方法用于檢查特定條件，并在否定結果上拋出AssertionError 。 JUnit運行時會拾取此類錯誤，并在結果報告中將測試標記為失敗。
2014年8月13日更新：使用org.junit.Assert只是一種可能。 JUnit還包括一個匹配器庫Hamcrest ，許多人認為它是關于干凈代碼的更好解決方案。 我個人最喜歡名為AssertJ的第三方庫的語法。
我認為Assert對于初學者而言可能更直觀，因此我為“ hello world”帖子選擇了Assert 。 由于對該決定的評論，我意識到至少在這一點上我不得不提到其他可能性。 我將在后續文章中詳細介紹Hamcrest和AssertJ的用法。
要斷言兩個值或對象相等，可以使用Assert#assertEquals 。 由于在聲明方法調用中使用靜態導入是很常見的，所以subsequentNumber測試可以像這樣完成：
@Testpublic void subsequentNumber() { NumberRangeCounter counter = new NumberRangeCounter();int first = counter.next();int second = counter.next();assertEquals( first + 1, second );}如您所見，測試指定了SUT的重要行為，甚至還不存在。 順便說一句，這也意味著測試類不再編譯！ 因此，下一步可能是創建我們部門的框架來解決此問題。
盡管本教程是關于JUnit而不是TDD的，但是我還是選擇了后者的方法，以強調干凈的JUnit測試用例所具有的規范字符。 這種方法將工作重點從單位的內部轉移到其使用和較低級別的要求上。
如果您想了解有關TDD的更多信息，特別是用于實現單個單元的“紅色/綠色/重構”口頭禪，可以讀一讀 Kent Beck的“ 示例驅動開發”或Lasse Koskela的“ 示例 驅動”一書。
下面的代碼片段顯示了NumberRangeCounter存根的外觀：
public class NumberRangeCounter {public int next() {return 0;} }再次運行測試，由于NumberRangeCounter#next()實現不足，現在導致出現紅條。 這可以確保通過無用的驗證或類似方式不會偶然滿足該規范：
除紅色條外，執行報告還顯示總共運行了多少測試，哪些測試因錯誤而終止以及有多少由于錯誤的斷言而失敗。 每個錯誤/失敗的堆棧跟蹤信息有助于在測試類中找到確切的位置。
AssertionError提供了一條解釋性消息，該消息顯示在故障跟蹤的第一行中。 錯誤測試可能表示任意編程錯誤，從而導致在測試的斷言語句之外引發Exception 。
注意，JUnit遵循全有或全無原則。 這意味著，如果一個測試運行涉及一個以上的測試（通常是這種情況），則單個測試的失敗將整個執行標記為紅色，表示失敗。
由于對于本文主題而言，特定單元的實際實現沒有多大意義，因此我將由您自己提出一個創新的解決方案，以使我們的第一個測試再次通過！
結論
前面的部分介紹了JUnit測試的基本知識–如何編寫，執行和評估它。 在這樣做的同時，我重視這樣的事實，即應該使用人們可能想到的最高編碼標準來開發此類測試。 給出的示例希望平衡得足夠好，以提供易于理解的介紹而又不瑣碎。 改進建議當然受到高度贊賞。
Nutshell文章中的下一個JUnit將繼續該示例，并涵蓋測試用例的一般概念及其四個階段的測試結構，請繼續關注。
翻譯自: https://www.javacodegeeks.com/2014/08/junit-in-a-nutshell-hello-world.html
junit:junit
總結
以上是生活随笔為你收集整理的junit:junit_简而言之，JUnit：Hello World的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 小米Redmi秋季新品发布会价格汇总：最
- 下一篇： 神话般的代码