單元測試-一份如何寫好單元測試的參考

yoylee_web發表於2019-01-21

目錄

系列導航

點選跳轉到系列博文目錄導航

開始

首先，單元測試是十分重要的，試想如果沒有單元測試，那麼如何保證程式碼能夠正常執行呢？測試人員做的只是業務上的整合測試，也就是黑盒測試，對單個的方法是沒有辦法測試的，而且，測試出的 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資料等

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

如果轉載此博文，請附上本文連結，謝謝合作~ ：https://blog.csdn.net/csdn___lyy

如果感覺這篇文章對您有所幫助，請點選一下“喜歡”或者“關注”博主，您的喜歡和關注將是我前進的最大動力！

refer:部落格 部落格 官網

相關文章