推 jack0204: 單元測試也能測SQL阿，有的框架支援記憶體儲存ORM07/14 21:42
是指記憶體型的db嗎？ 但我們用的是mybatis這種object mapping 的框架，用的是MySQL
怕有些MySQL 特有的語法會不支援， 再來我們還有其他微服務用到mongodb and redis
推 art1: 測得不完全也比完全不測好07/14 21:43
是沒錯
→ jack0204: 不然就是建一個stage環境配migrate執行完整測試07/14 21:43
→ jack0204: 如果測試案例不好那就把他寫到好阿，不然寫爽的膩?07/14 21:44
是阿 不過現況是公司有一半的成員是junior 可能要費點心思了
→ jack0204: 整合測試是因為測一整次很花時間，單元測試就快多了07/14 21:45
推 jack0204: 單元(純邏輯)/功能(假DB)/整合測試看你們想做到哪一步07/14 21:51
→ pigcat1315: 沒SDET部門就坐單元測試就好 不然測試的龐大你寫不完07/14 21:55
我也這樣認為，但老闆認為 整合測試是要給工程師寫的，不過在資源有限的公司裡確實也
是這樣就是了
推 sojoasd: 小的淺短的建議：專案還在開發階段時，寫測試DB比較好，07/14 22:04
→ sojoasd: 因爲這時期schema可能常常變動，當然就是比較麻煩。另外07/14 22:04
→ sojoasd: 串接微服務可能改成其他排程task定時執行測試會比較好07/14 22:04
→ 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
推 supernow: 我們這邊單元測試不直接打db，是直接mock掉只驗sql語法07/14 22:52
→ 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
推 supernow: 至於測試案例寫不好這只能靠code review多電幾次才能改 07/14 22:55
→ 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
推 sharku: 單元測試的DB只在執行時產生 測試完後刪除 不連到實體DB 07/14 23:15
→ pass78: h2 07/14 23:20
推 lywctl: 單元測試時通常會用到mock跟假資料的方式來幫助測試 07/15 01:49
→ lywctl: 1.Mock是用在跟這個method要做的事沒直接相關時 比如現在 07/15 01:49
→ lywctl: 測試一個修改使用者訂單的數量 裡面有一個function是要知 07/15 01:49
→ lywctl: 道判斷該使用者的權限 這時後就會用mock的方式指定使用者 07/15 01:49
→ lywctl: 權限2.假如是要測試更改資料庫的method時 應該是要用新增 07/15 01:49
→ lywctl: 假資料的方式 並用該筆資料來做測試 而不是用mock 的方式 07/15 01:49
推 art1: 假裝使用者有此權限跟提供假資料，差異是權限跟資料嗎？ 07/15 05:41
→ supernow: 18樓的case.2我們這邊會驗的就是修改的程式有沒有被呼叫 07/15 08:11
→ supernow: 到，傳進來的參數是否正確，還是不會去打db，直接打db變 07/15 08:11
→ supernow: 數太多如網路、資料庫健康..等，這不應該是單元測試要關 07/15 08:11
→ supernow: 注的點 07/15 08:11
推 adks3489: 單元測試用mock測語法，整合測試才連DB 07/15 09:55
→ adks3489: 基本上是兩者都要做 07/15 09:56
推 lywctl: @art1 差異在於一個是直接回傳一個結果 一個是產生一筆資 07/15 17:54
→ lywctl: 料去做後續的測試 07/15 17:54
推 lywctl: @adk 單元測試要測試的應該是輸入的值相對應到輸出的結果 07/15 17:56
→ lywctl: 所有在case2時應該是會在測試的db裡產生假資料去做測試 07/15 17:56
推 lywctl: 至於提到的網路或是第三方資料 這些都是外部資料應該另外 07/15 17:59
→ lywctl: 做mock 這算是case1 而資料庫健康..這個應該是設計程式的 07/15 17:59
→ lywctl: 問題吧 07/15 17:59
→ supernow: 跟db互動應該交給 repository method,單元測試需要的db 07/15 19:34
→ supernow: 資料就mock repository method取得 07/15 19:34
推 lywctl: @super 假如會把跟db活動的都拆出來的話的確在測試其他me 07/15 23:25
→ lywctl: thod時會用mock的方式 這也是前面提到的case1 07/15 23:25
→ lywctl: 但repository method也會有單元測試 這時候他的資料就應 07/15 23:26
→ lywctl: 該是要生成假資料的方式來進行 07/15 23:26
→ lywctl: Ps: case1 跟case2並不一定是單獨存在 實務上通常兩個會 07/15 23:27
→ lywctl: 一起用 07/15 23:27
推 lywctl: 比如前面提到的例子 07/15 23:32
→ lywctl: 測試一個function是要依據該使用者的權限 將原本訂單的數 07/15 23:32
→ lywctl: 量改成不同值 07/15 23:32
→ lywctl: 這時候會先產生一筆訂單的假資料 並且使用mock的方式指定 07/15 23:33
→ lywctl: 使用者的權限 去測試這個method 07/15 23:33
推 supernow: 你的例子我們這邊會mock訂單repository取得訂單，再mock 07/16 01:02
→ supernow: 權限取得權限，再mock 訂單 repository更新訂單後的結 07/16 01:02
→ supernow: 果，單元測試還是不應該去實際打db 07/16 01:02
→ supernow: 實際打db都應該交給整合測試做 07/16 01:03
推 Csongs: 如果原本沒有寫單元測試，不如先寫測整合測試，比較能快速 07/16 16:47
→ Csongs: 看到成效 07/16 16:47
→ Csongs: 單元測試要補的話，建議先寫邏輯複雜的地方，不好寫單元測 07/16 16:49
→ Csongs: 試通常是因為寫code的當下就沒有想過如何測試，這時候要重 07/16 16:49
→ Csongs: 構代碼反而也麻煩 07/16 16:49