Unit Test

「單元測試的藝術」讀書會 - 用 stubs 解除相依 (The Art of Unit Testing, 3e - Breaking dependencies with stubs) 閱讀筆記。 解除相依性 在測試 SUT ( stand for system under test)，可能會遇到一些外部的相依，讓測試變得不可靠而且脆弱。這個時候我們就需要想辦法跟這些我們無法控制的元件/系統或是服務解除相依，讓這些東西可以在我們的掌控之下。 這邊依據 SUT 跟該服務的互動方式區分為 Outgoing dependency 和 Incoming dependency --- title: Outgoing dependency --- flowchart LR UST{{"Unit of work"}} test((Test)) Dep{{"Dependency"}} test--Entry point-->UST UST--Exit point-->Dep 這個類型的相依通常是 API 通知、打 webhook、寫 log 或是存資料到 DB。這些會帶有 通知、呼叫 或是 發送 的行為通常就是 outgoing 相依的特徵，這些行為都有把流程（或資料） 帶出 這個 unit of work 因此每一個都是一個 exit point。 ...

寫了 Unit Test 然後呢 一般來說談到要讓程式碼的品質變好，多數人想到的除了規範團隊的 Coding Style 、Code Review 之外，就屬撰寫 Unit test 來確保 production code 可以確實符合商業需求。 但是這邊就有一個問題產生了，究竟我要寫多少單元測試才夠呢？我的覆蓋率已經 100% 了，是否代表萬無一失了？但 100% 根本神話，而且這樣要寫超多單元測試，寫測試的時間都可以拿來做下一個需求了。。。 上述的問題在尚未引入 Mutation test 之前看起來是真的挺無解，也容易陷入覆蓋率的迷思之中。 Mutation Test 是什麼 Mutation test 說實話不是個新概念，他的歷史應該可以往回推到 1978 年的這篇論文。他的基本概念就是藉由改變 production code 來檢驗你的單元測試能否抓到這些改變，若能夠抓到就代表你的測試能夠確保目前的程式碼夠強健，能夠確保在商業邏輯改變後你可以知道什麼東西會跟以前不同。反之，若改變 production code 後單元測試卻沒有反應出來，就代表需要再補強單元測試。 會用到的必要 Packages junit official site org.pitest official site junit 目前第五版也是可以使用 PIT，不過作法比較不同，需要引用不同的 Packages，可以參考這個來試試。 Demo Code source code：github repo 範例程式 以下這個是一個迴文函式，目的是用來判斷一個傳入的字串是否屬於迴文。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 public class Palindrome { public boolean isPalindrome(String inputString) { if (inputString.length() == 0) { return true; } else { char firstChar = inputString.charAt(0); char lastChar = inputString.charAt(inputString.length() - 1); String mid = ""; if (inputString.length() > 1){ mid = inputString.substring(1, inputString.length() - 1); } return (firstChar == lastChar) && isPalindrome(mid); } } } 以下則是這個函式的測試程式 ...