聊一聊，單元測試應該測試什麼？

開始

如今大公司愈來愈重視項目的單元測試，甚至明確要求項目的單元測試覆蓋率不能低於某個值，足可見單元測試的重要性；

試想若是沒有單元測試，那麼如何保證代碼可以正常運行呢？

測試人員作的只是業務上的集成測試，也就是黑盒測試，對單個的方法是沒有辦法測試的，並且，測試出的 bug 的範圍也會很廣，根本不能肯定 bug 的範圍，還得去花時間來肯定 bug 出在什麼地方。

另外，一個最多見的問題：寫單測浪費時間？ 你有沒有計算過你改bug的時間（定位+修復），算一下的話你會發現時間浪費的會更多。

參考建議

關於如何寫好單元測試，下面有幾條建議供你們參考：

1. 測試數據外部化

測試數據大體分爲兩種：變化的和不變化的，對於不變的測試數據，咱們徹底能夠寫在單元測試用例代碼中，也能夠將數據外部化。

而對於測試數據一直在變，而且測試數據量比較大的時候可使用測試數據外部化將數據放在測試用例的外部進行統一管理。

什麼是數據外部化？就是將數據放在單元測試用例的外部統一管理，好比咱們能夠將一個單元測試用例中的測試數據統一放在一個CSV文件中。

咱們就能夠經過好比junit5中的參數測試註解@ParameterizedTest和引入CVS文件的註解@CsvFileSource並指定其中的resources屬性指定CSV文件，numLinesToSkip = n 屬性指定從第n+1行開始。這樣就能夠經過一個CSV文件統一管理一個單元測試用例中的數據。

咱們管理測試用例中所須要的數據就只須要管理一個個CSV文件便可。

下面能夠看一個案例：（其中具體的使用方法請看博客[junit5系列-參數化測試]()）

@ParameterizedTest
@CsvFileSource(resources = "/two-column.csv", numLinesToSkip = 1)
void testWithCsvFileSource(String first, int second) {
    assertNotNull(first);
    assertNotEquals(0, second);
}

其中，two-column.csv文件內容

Country, reference
Sweden, 1
Poland, 2
"United States of America", 3

2. 構建具備特定結果的測試

• 若是方法結果具備隨機性，這樣的方法幾乎沒法測試，因此咱們針對這種方法便沒有辦法去進行測試。

  • 咱們只能對根據特有數據獲得特定結果的方法進行測試。

3. 測試方面全面，設計的每一方面必須有一個測試用例：

• 正面全部情景
• 負面全部情景
• 臨界值
• 特殊值

4. 測試用例請儘可能簡潔、簡短

在能完成測試的基礎上儘可能簡潔代碼，這樣不只使代碼更加好看，還好維護好理解。
想一想一大堆代碼和幾行代碼你更想看哪一個？

5. 測試用例儘可能快

對於單元測試用例咱們幾乎每開發完一個方法或者修改完一個方法，咱們幾乎都會去運行一遍測試用例，確保沒有影響到其餘模塊的正常運行，因此咱們要儘可能讓你的測試方法「快！」，移除一些和單元測試無關的代碼。固然，前提仍是要保證測試的完整性與正確性。

6. 每次運行單元測試時，請確保100%運行成功！

這個相對來講比較簡單，可是作起來是比較難的，由於可能會有多種緣由致使你的測試用例失敗，好比：數據過時、方法內部邏輯改變等。

這些可能會花費你的一些時間去修改，你每每可能不肯意，不過既然作了一件事，就作好一件事唄

可是若是你不注意這些小錯誤，這可能就會致使你的一個大流程失敗，你們應該知道，咱們在運行一個流程時每每一個小小的錯誤就致使流程整理失敗！

7. 設計好你的測試

這包含的方面就比較廣了，下面幾個方面我認爲你們應該注意的：

• 前面所說的代碼在保證質量的前提下儘可能簡潔
• 單元測試中代碼的抽象也是能夠有的，咱們也能夠將一些可重用的代碼抽象出來，提升代碼的重用性和減小代碼的重複。
• 給測試類測試方法起一個好名字。測試類通常是「類名+Test後綴」，能夠表示對哪一個類進行的測試。測試方法也是相似，「測試方法名+Test後綴」或者對一個方法的部分測試「測試方法名+測試部分做用+Test後綴」。
• 每一個測試方法對被測試方法的功能斷言不宜過多，若是一個方法須要多個斷言進行測試，咱們能夠進行大體分類，將其分不到兩個測試方法中，這樣能夠細粒度的進行測試。

8. 注意測試代碼覆蓋率

一個設計好的單元測試，其代碼測試覆蓋率也是很高的，並不要求100% 的測試代碼覆蓋率，可是高覆蓋率的代碼包含未檢測到的錯誤的概率要低，由於其更多的源代碼在測試過程當中被執行。

注意：高代碼覆蓋不能保證測試是完美的，因此要當心！

9. 還有就是一些其餘的注意點了，好比

• 不要使用print語句去輸出測試結果人工判斷是否正確，要使用斷言
• 一些很差理解的測試最好在方法上面寫明註釋，便於後期理解與維護
• 使用框架進行單元測試，好比Junit5若是其中的斷言支持不知足你的需求也可使用ASsertJ框架來豐富斷言，Mockito進行Mock數據等

好了，上述就是對如何寫好單元測試的一些建議，若有不當，請在評論區中指出，感激涕零！

接下來，我會寫一些關於單元測試如何搭建、junit5相關新語法、基於圖數據庫的單元測試等
歡迎關注博主和 公衆號[匠心Java]，一塊兒討論~

refer:博客 博客 官網