[請益] 測試程式問題

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