[請益] 如何實現單元測試多於整合測試？

devilkool11/20 01:57以傳統三層式架構來說我多半是測中間的商業邏輯層

TSW11/20 02:43看情況，只要整合測試寫/改起來不累，單元測試就沒那麼重要

TSW11/20 02:49數量差距不用太在意，只要好寫又有效，多一點無妨

DrTech11/20 11:41實務上，單元測試不是看數量多少，是看覆蓋率。整合測試不

DrTech11/20 11:41是工程師在開發環境寫單元測試，而是在測試環境，QA寫。

DrTech11/20 11:42簡單說，從來不追求數量。追求覆蓋。

labbat11/20 18:02小公司不會有賠錢部門QA的

strlen11/21 15:56不用在意數量多寡 測試數量會根據你做的架構或軟體類型變

strlen11/21 15:57化是很正常的一件事 像你說你API都CRUD 那當然單元測試就

strlen11/21 15:57都通常在測處理資料的商業邏輯 但要是那些邏輯也沒啥好測

strlen11/21 15:58就甭測了 因為本來就沒啥好測 但如果你是做個圖像引擎之類

strlen11/21 15:58的東西 單元測試就會變得比較多 因為運算也比較多 合理吧

superpandal11/21 19:34當然是直接整合測試就好 專案失控才要整天搞單元測試

superpandal11/21 19:36而且ide可以單步除錯 真的要測也不用annotation的爛

superpandal11/21 19:36方式

superpandal11/21 19:37一勞永逸讓專案可控才是最佳品質保證

acgotaku11/22 10:57你寫db/cache用DI寫 可以很方便的 mock 這些依賴

acgotaku11/22 10:59但是也有不少做法是在測試時 用你的 db entity 真實建

acgotaku11/22 11:00一個db 在緩存中, 這樣測試有一個優點 就是確保你entity

acgotaku11/22 11:00是正確的,也可以符合你實際連線的狀況 缺點就是麻煩

acgotaku11/22 13:02上面有說CRUD邏輯簡單就不用單元測試,這是很嚴重的錯誤

acgotaku11/22 13:04單元測試為何講求覆蓋率,就是要確保可靠度是有保障的

acgotaku11/22 13:06單元邏輯有沒有正確,只是其中之一 不是全部

superpandal11/22 21:09CRUD是很制式化的技術應用 想方設法使程式碼簡潔且邏

superpandal11/22 21:11輯圓融 做到這一步即便你不寫測試多半應用不會有錯

superpandal11/22 21:12見到更多的是程式碼亂七八糟寫測試想hold住質量的...

superpandal11/22 21:17當然已經是屎山的就冏了

superpandal11/22 21:20別人的產品可以不必搞到這樣 但有某種程度方便很多