junit！=單元測試

Junit是Java單元測試框架。 通常，我們將其用于單元測試，但是很多時候我們也使用它來執行集成測試。 主要區別在于，單元測試可測試單個單元，而集成測試則可測試不同類如何協同工作。 這樣，集成測試可以覆蓋更長的執行鏈。 這意味著它們可能比單元測試發現更多的錯誤，但同時它們通常運行更長的時間，并且如果測試失敗，則更難定位錯誤。 如果您（作為開發人員）意識到這些差異，那么使用junit執行非單元測試就沒有錯。

當使用junit框架執行系統測試時，我已經在生產代碼中看到了示例，其中測試的執行鏈包括通過網絡進行的外部服務調用。 Junit只是一種工具，因此，即使您知道其缺點，也沒有本質上的問題。 但是，在實際情況下，junit測試的執行是在正常的maven測試階段執行的，并且一旦外部服務中斷，代碼就無法構建。 這很不好，因為清楚地表明開發人員在創建代碼時并未意識到包括外部服務和構建過程在內的全局情況。

說完這些之后，讓我告訴您一個不同的故事，稍后再加入這兩個主題。

我們說語言...很多

大多數時候，我們的程序都有用戶界面。 該界面包含文本，通常使用不同的語言。 通常以目標代碼為英文和當地語言。 文本文字通常是外部化的，存儲在“屬性”文件中。 對于多種語言，我們為每種語言都有單獨的屬性文件，每種屬性文件都為id定義文字文本。

例如我們有文件

messages-de.properties messages-fr.properties messages-en.properties messages-pl.properties messages.properties

在Java代碼中，我們通過Spring MessageSource調用來訪問它們

String label = messageSource.getMessage("my.label.name",null,"label",locale);

我們，程序員有點懶

當我們沒有一些文本翻譯時，問題就來了。 用不同語言指定標簽實際文本的工作不屬于程序員。 程序員是精通Java，C和其他編程語言的人，但是當談到自然語言時，他們并不那么光彩。 我們大多數人不會說所有需要的語言。 有人負責翻譯文本。 通常，不同的人使用不同的語言。 其中一些工作速度更快，另一些工作速度較慢，編碼只是迫不及待準備好翻譯。 在最終翻譯可用之前，我們使用臨時字符串。

所有臨時解決方案都將成為最終解決方案。

臨時字符串（只是英文版）進入了發行版。

流程和紀律：失敗

為了避免這種情況，我們實施了一個流程。 我們為每種翻譯打開了一個Jira問題。 翻譯準備就緒后，它便會附在問題上。 當將其編輯到屬性文件中并提交到git時，問題已關閉。 如此沉重的負擔和開銷使程序員為此放慢了速度，而紀律不明的程序員只是沒有遵循該過程。 通常這是一個壞主意。

我們得出的結論是，不轉換為屬性文件并不是真正的大問題。 問題是不知道它丟失并創建發行版。 因此，我們需要一個過程在發布之前檢查屬性文件的正確性。

光路過程與控制

手動檢查會很麻煩。 我們創建了junit測試，比較了不同的語言文件，并檢查了另一個語言文件中是否沒有鍵，并且這些值與默認的英語版本不相同。 每次發布項目時都要執行junit測試。 然后我們意識到其中一些值確實與英文版本相同，因此我們開始在語言文件的第一個位置使用字母“ X”來表示等待實際翻譯值替換的標簽。 在這一點上，有人建議可以將junit測試替換為簡單的“ grep”。 幾乎是事實，只是我們仍然希望發現丟失的鍵并在發布過程中自動測試運行。

總結和總結

Junit框架旨在執行單元測試，但是框架不僅可以用于其設計目的，而且可以并且將被使用。 （附帶說明：對于任何工具，實際上都是正確的，無論是像錘子一樣簡單，還是像Java接口中的默認方法一樣復雜。）

您可以使用junit執行可以在構建和/或發布的測試階段執行的任務。

• 任務應該快速執行，因為執行時間會增加構建/發布周期。
• 不應依賴外部資源，尤其是通過網絡可訪問的外部資源，
  因為這些故障可能還會導致構建過程失敗。
• 如果某些內容對于構建不可接受，請使用junit api發出失敗信號。 不要只寫警告。 沒有人閱讀警告。

翻譯自: https://www.javacodegeeks.com/2015/02/using-junit-something-else.html

總結

以上是生活随笔為你收集整理的使用junit做其他事情的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。