請教一下版上前輩測試方面的問題
我們公司的產品是有著微服務架構的後端服務，最近想導入測試但是在開會時對於測試的方
式與方向跟夥伴們有些意見分歧，想聽聽版上前輩的意見。
1. 單元測試： 我的想法是單元測試是針對每個method做測試目的是希望每個method都能符
合預期不會改a錯b. 單元測試也不應該與外部相依，比如說資料庫應該都用mock DAO 的方
式來測試。
不過夥伴認為我們應該也要連sql都一起測試，不然我怎麼知道sql是否正確？(意見不同1)
，寫測試程式很容易因為測試案例不好而導致測試測的不完全，寫這測試會很沒意義（意見
不同2）
2. 整合測試： 老闆認為有單元測試只不過方便日後重構而已，還不如來寫整合測試（打HT
TP request 測試） （意見不同3）
我的想法是
意見1: 可以延到整合測試測，因為單元測試目的是在於驗證程式碼有無如預期進行，且應
該要可以快速測試驗證。
意見2: 可以用測試覆蓋率為參考依據
意見3：因為整合測試無法有效提昇覆蓋率，且有環境等因素考量，也跟業務邏輯牽扯 （塞
資料順序等等），反而門檻更高。
不知道版上前輩有什麼其他想法嗎？
或者其實我觀念有錯誤？
謝謝

單元測試也能測SQL阿，有的框架支援記憶體儲存ORM

測得不完全也比完全不測好

不然就是建一個stage環境配migrate執行完整測試如果測試案例不好那就把他寫到好阿，不然寫爽的膩?整合測試是因為測一整次很花時間，單元測試就快多了單元(純邏輯)/功能(假DB)/整合測試看你們想做到哪一步

沒SDET部門就坐單元測試就好 不然測試的龐大你寫不完

小的淺短的建議：專案還在開發階段時，寫測試DB比較好，因爲這時期schema可能常常變動，當然就是比較麻煩。另外串接微服務可能改成其他排程task定時執行測試會比較好

單元測試也可以測SQL 看你後端用什麼框架而定

我們這邊單元測試不直接打db，是直接mock掉只驗sql語法，跟你的想法一樣，另外在整合測試裡才實際連db至於測試案例寫不好這只能靠code review多電幾次才能改善

單元測試的DB只在執行時產生 測試完後刪除 不連到實體DB

h2

單元測試時通常會用到mock跟假資料的方式來幫助測試1.Mock是用在跟這個method要做的事沒直接相關時 比如現在測試一個修改使用者訂單的數量 裡面有一個function是要知道判斷該使用者的權限 這時後就會用mock的方式指定使用者權限2.假如是要測試更改資料庫的method時 應該是要用新增假資料的方式 並用該筆資料來做測試 而不是用mock 的方式

假裝使用者有此權限跟提供假資料，差異是權限跟資料嗎？

18樓的case.2我們這邊會驗的就是修改的程式有沒有被呼叫到，傳進來的參數是否正確，還是不會去打db，直接打db變數太多如網路、資料庫健康..等，這不應該是單元測試要關注的點

單元測試用mock測語法，整合測試才連DB基本上是兩者都要做

@art1 差異在於一個是直接回傳一個結果 一個是產生一筆資料去做後續的測試@adk 單元測試要測試的應該是輸入的值相對應到輸出的結果所有在case2時應該是會在測試的db裡產生假資料去做測試至於提到的網路或是第三方資料 這些都是外部資料應該另外做mock 這算是case1 而資料庫健康..這個應該是設計程式的問題吧

跟db互動應該交給 repository method,單元測試需要的db資料就mock repository method取得

@super 假如會把跟db活動的都拆出來的話的確在測試其他method時會用mock的方式 這也是前面提到的case1但repository method也會有單元測試 這時候他的資料就應該是要生成假資料的方式來進行Ps: case1 跟case2並不一定是單獨存在 實務上通常兩個會一起用比如前面提到的例子測試一個function是要依據該使用者的權限 將原本訂單的數量改成不同值這時候會先產生一筆訂單的假資料 並且使用mock的方式指定使用者的權限 去測試這個method

你的例子我們這邊會mock訂單repository取得訂單，再mock權限取得權限，再mock 訂單 repository更新訂單後的結果，單元測試還是不應該去實際打db實際打db都應該交給整合測試做

如果原本沒有寫單元測試，不如先寫測整合測試，比較能快速看到成效單元測試要補的話，建議先寫邏輯複雜的地方，不好寫單元測試通常是因為寫code的當下就沒有想過如何測試，這時候要重構代碼反而也麻煩