《JUnit實戰（第2版）》—— 1.3 了解單元測試架構

本節書摘來異步社群《junit實戰（第2版）》一書中的第1章，第1.3節，作者：【美】petar tahchiev , felipe leme , vincent massol , gary gregory，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

junit實戰（第2版）

單元測試架構應該遵循以下幾條最佳實踐規則。calculatortest程式中一些不起眼的改進就突出展現了所有單元測試架構應該遵循（按照我們的經驗）的三大規則：

每個單元測試都必須獨立于其他所有單元測試而運作；

架構應該以單個測試為機關來檢測和報告錯誤；

應該易于定義要運作哪些單元測試。

“稍好一點”的calculatortest程式雖然向以上規則靠攏了，但仍然存在着不足。例如，為了使每個單元測試能夠真正獨立運作，就應該在不同的類執行個體中運作它們，理想的情況是在不同的類加載器（class loader）執行個體中運作它們。

我們現在能夠通過增加一個新的方法并且在main中增加一個對應的try/catch塊來增加新的單元測試。顯然，這是一個進步，但是在真正的單元測試集中，這樣做還遠遠不夠。經驗告訴我們，很大的try/catch塊會帶來諸多元護問題。我們很可能遺漏一個單元測試并且還對此毫無意識！

如果我們可以增加新的測試方法并繼續正常工作，那真是太好了。但是，程式又是如何知道要運作哪些方法呢？好吧，我們應該有一個簡單的注冊過程。一個注冊方法至少可以盤點哪些測試正在運作。

另一種方法是使用java的reflection和introspection功能。程式可以檢查自身并決定要運作任何遵循某種命名協定的方法，例如，以“test”開頭的方法。

對于單元測試架構而言，使增加測試變得更加簡單（上文中提到的第3條規則）聽起來像是另一條不錯的規則。為了滿足這條規則（通過注冊或自我檢測），還需要編寫大量的支援代碼，但這将是值得的。雖然起初的工作量會很大，但是随着每次我們增加一個新的測試，所有的努力都會得到回報。

令人高興的是，junit團隊為我們解決了這個麻煩。junit架構已經支援自我檢測方法。它也支援針對每個測試使用不同的類執行個體和類加載器執行個體，并逐個報告每個測試的所有錯誤。既然你已經明白了你為什麼要需要一個單元測試架構，那麼就讓我們進一步來了解junit。

本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。