作者VFCanisLupus (CanisLupus)
看板Soft_Job
標題[請益] 測試程式問題
時間Sun Jul 14 21:17:20 2019
請教一下版上前輩測試方面的問題
我們公司的產品是有著微服務架構的後端服務，最近想導入測試但是在開會時對於測試的方
式與方向跟夥伴們有些意見分歧，想聽聽版上前輩的意見。
1. 單元測試： 我的想法是單元測試是針對每個method做測試目的是希望每個method都能符
合預期不會改a錯b. 單元測試也不應該與外部相依，比如說資料庫應該都用mock DAO 的方
式來測試。
不過夥伴認為我們應該也要連sql都一起測試，不然我怎麼知道sql是否正確？(意見不同1)
，寫測試程式很容易因為測試案例不好而導致測試測的不完全，寫這測試會很沒意義（意見
不同2）
2. 整合測試： 老闆認為有單元測試只不過方便日後重構而已，還不如來寫整合測試（打HT
TP request 測試） （意見不同3）
我的想法是
意見1: 可以延到整合測試測，因為單元測試目的是在於驗證程式碼有無如預期進行，且應
該要可以快速測試驗證。
意見2: 可以用測試覆蓋率為參考依據
意見3：因為整合測試無法有效提昇覆蓋率，且有環境等因素考量，也跟業務邏輯牽扯 （塞
資料順序等等），反而門檻更高。
不知道版上前輩有什麼其他想法嗎？
或者其實我觀念有錯誤？
謝謝
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 27.242.203.105 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1563110242.A.161.html
1F：推 jack0204: 單元測試也能測SQL阿，有的框架支援記憶體儲存ORM07/14 21:42
是指記憶體型的db嗎？ 但我們用的是mybatis這種object mapping 的框架，用的是MySQL
怕有些MySQL 特有的語法會不支援， 再來我們還有其他微服務用到mongodb and redis
2F：推 art1: 測得不完全也比完全不測好07/14 21:43
是沒錯
3F：→ jack0204: 不然就是建一個stage環境配migrate執行完整測試07/14 21:43
4F：→ jack0204: 如果測試案例不好那就把他寫到好阿，不然寫爽的膩?07/14 21:44
是阿 不過現況是公司有一半的成員是junior 可能要費點心思了
5F：→ jack0204: 整合測試是因為測一整次很花時間，單元測試就快多了07/14 21:45
6F：推 jack0204: 單元(純邏輯)/功能(假DB)/整合測試看你們想做到哪一步07/14 21:51
7F：→ pigcat1315: 沒SDET部門就坐單元測試就好 不然測試的龐大你寫不完07/14 21:55
我也這樣認為，但老闆認為 整合測試是要給工程師寫的，不過在資源有限的公司裡確實也
是這樣就是了
8F：推 sojoasd: 小的淺短的建議：專案還在開發階段時，寫測試DB比較好，07/14 22:04
9F：→ sojoasd: 因爲這時期schema可能常常變動，當然就是比較麻煩。另外07/14 22:04
10F：→ sojoasd: 串接微服務可能改成其他排程task定時執行測試會比較好07/14 22:04
11F：→ sharku: 單元測試也可以測SQL 看你後端用什麼框架而定07/14 22:08
單元測試也可以測試sql嗎 小弟去研究看看
※ 編輯: VFCanisLupus (27.242.203.105 臺灣), 07/14/2019 22:47:00
※ 編輯: VFCanisLupus (27.242.203.105 臺灣), 07/14/2019 22:50:39
12F：推 supernow: 我們這邊單元測試不直接打db，是直接mock掉只驗sql語法07/14 22:52
13F：→ supernow: ，跟你的想法一樣，另外在整合測試裡才實際連db 07/14 22:52
※ 編輯: VFCanisLupus (27.242.203.105 臺灣), 07/14/2019 22:53:39
※ 編輯: VFCanisLupus (27.242.203.105 臺灣), 07/14/2019 22:55:13
14F：推 supernow: 至於測試案例寫不好這只能靠code review多電幾次才能改 07/14 22:55
15F：→ supernow: 善 07/14 22:55
了解 感謝回覆
※ 編輯: VFCanisLupus (27.242.203.105 臺灣), 07/14/2019 22:57:20
※ 編輯: VFCanisLupus (27.242.203.105 臺灣), 07/14/2019 22:58:05
16F：推 sharku: 單元測試的DB只在執行時產生 測試完後刪除 不連到實體DB 07/14 23:15
17F：→ pass78: h2 07/14 23:20
18F：推 lywctl: 單元測試時通常會用到mock跟假資料的方式來幫助測試 07/15 01:49
19F：→ lywctl: 1.Mock是用在跟這個method要做的事沒直接相關時 比如現在 07/15 01:49
20F：→ lywctl: 測試一個修改使用者訂單的數量 裡面有一個function是要知 07/15 01:49
21F：→ lywctl: 道判斷該使用者的權限 這時後就會用mock的方式指定使用者 07/15 01:49
22F：→ lywctl: 權限2.假如是要測試更改資料庫的method時 應該是要用新增 07/15 01:49
23F：→ lywctl: 假資料的方式 並用該筆資料來做測試 而不是用mock 的方式 07/15 01:49
24F：推 art1: 假裝使用者有此權限跟提供假資料，差異是權限跟資料嗎？ 07/15 05:41
25F：→ supernow: 18樓的case.2我們這邊會驗的就是修改的程式有沒有被呼叫 07/15 08:11
26F：→ supernow: 到，傳進來的參數是否正確，還是不會去打db，直接打db變 07/15 08:11
27F：→ supernow: 數太多如網路、資料庫健康..等，這不應該是單元測試要關 07/15 08:11
28F：→ supernow: 注的點 07/15 08:11
29F：推 adks3489: 單元測試用mock測語法，整合測試才連DB 07/15 09:55
30F：→ adks3489: 基本上是兩者都要做 07/15 09:56
31F：推 lywctl: @art1 差異在於一個是直接回傳一個結果 一個是產生一筆資 07/15 17:54
32F：→ lywctl: 料去做後續的測試 07/15 17:54
33F：推 lywctl: @adk 單元測試要測試的應該是輸入的值相對應到輸出的結果 07/15 17:56
34F：→ lywctl: 所有在case2時應該是會在測試的db裡產生假資料去做測試 07/15 17:56
35F：推 lywctl: 至於提到的網路或是第三方資料 這些都是外部資料應該另外 07/15 17:59
36F：→ lywctl: 做mock 這算是case1 而資料庫健康..這個應該是設計程式的 07/15 17:59
37F：→ lywctl: 問題吧 07/15 17:59
38F：→ supernow: 跟db互動應該交給 repository method,單元測試需要的db 07/15 19:34
39F：→ supernow: 資料就mock repository method取得 07/15 19:34
40F：推 lywctl: @super 假如會把跟db活動的都拆出來的話的確在測試其他me 07/15 23:25
41F：→ lywctl: thod時會用mock的方式 這也是前面提到的case1 07/15 23:25
42F：→ lywctl: 但repository method也會有單元測試 這時候他的資料就應 07/15 23:26
43F：→ lywctl: 該是要生成假資料的方式來進行 07/15 23:26
44F：→ lywctl: Ps: case1 跟case2並不一定是單獨存在 實務上通常兩個會 07/15 23:27
45F：→ lywctl: 一起用 07/15 23:27
46F：推 lywctl: 比如前面提到的例子 07/15 23:32
47F：→ lywctl: 測試一個function是要依據該使用者的權限 將原本訂單的數 07/15 23:32
48F：→ lywctl: 量改成不同值 07/15 23:32
49F：→ lywctl: 這時候會先產生一筆訂單的假資料 並且使用mock的方式指定 07/15 23:33
50F：→ lywctl: 使用者的權限 去測試這個method 07/15 23:33
51F：推 supernow: 你的例子我們這邊會mock訂單repository取得訂單，再mock 07/16 01:02
52F：→ supernow: 權限取得權限，再mock 訂單 repository更新訂單後的結 07/16 01:02
53F：→ supernow: 果，單元測試還是不應該去實際打db 07/16 01:02
54F：→ supernow: 實際打db都應該交給整合測試做 07/16 01:03
55F：推 Csongs: 如果原本沒有寫單元測試，不如先寫測整合測試，比較能快速 07/16 16:47
56F：→ Csongs: 看到成效 07/16 16:47
57F：→ Csongs: 單元測試要補的話，建議先寫邏輯複雜的地方，不好寫單元測 07/16 16:49
58F：→ Csongs: 試通常是因為寫code的當下就沒有想過如何測試，這時候要重 07/16 16:49
59F：→ Csongs: 構代碼反而也麻煩 07/16 16:49