→ devilkool: 以傳統三層式架構來說我多半是測中間的商業邏輯層 11/20 01:57
單元測試確實是測商業邏輯的部份，我的專案含有商業邏輯的程式不多，變成都在寫整合測試
推 TSW: 看情況，只要整合測試寫/改起來不累，單元測試就沒那麼重要 11/20 02:43
推 TSW: 數量差距不用太在意，只要好寫又有效，多一點無妨 11/20 02:49
→ DrTech: 實務上，單元測試不是看數量多少，是看覆蓋率。整合測試不 11/20 11:41
→ DrTech: 是工程師在開發環境寫單元測試，而是在測試環境，QA寫。 11/20 11:41
→ DrTech: 簡單說，從來不追求數量。追求覆蓋。 11/20 11:42
了解，爬文看到測試金字塔提到層次越高的測試應該會越少，所以才想是否寫錯了，另外，公司目前沒有QA，所有測試都是工程師寫
→ labbat: 小公司不會有賠錢部門QA的 11/20 18:02
推 strlen: 不用在意數量多寡 測試數量會根據你做的架構或軟體類型變 11/21 15:56
→ strlen: 化是很正常的一件事 像你說你API都CRUD 那當然單元測試就 11/21 15:57
→ strlen: 都通常在測處理資料的商業邏輯 但要是那些邏輯也沒啥好測 11/21 15:57
→ strlen: 就甭測了 因為本來就沒啥好測 但如果你是做個圖像引擎之類 11/21 15:58
→ strlen: 的東西 單元測試就會變得比較多 因為運算也比較多 合理吧 11/21 15:58
我目前的情況就是這樣，運算的商業邏輯不多，API CRUD 寫整合測試就會比單元測試還多。
→ superpandal: 當然是直接整合測試就好 專案失控才要整天搞單元測試 11/21 19:34
→ superpandal: 而且ide可以單步除錯 真的要測也不用annotation的爛 11/21 19:36
→ superpandal: 方式 11/21 19:36
→ superpandal: 一勞永逸讓專案可控才是最佳品質保證 11/21 19:37
→ acgotaku: 你寫db/cache用DI寫 可以很方便的 mock 這些依賴 11/22 10:57
→ acgotaku: 但是也有不少做法是在測試時 用你的 db entity 真實建 11/22 10:59
→ acgotaku: 一個db 在緩存中, 這樣測試有一個優點 就是確保你entity 11/22 11:00
→ acgotaku: 是正確的,也可以符合你實際連線的狀況 缺點就是麻煩 11/22 11:00
→ acgotaku: 上面有說CRUD邏輯簡單就不用單元測試,這是很嚴重的錯誤 11/22 13:02
→ acgotaku: 單元測試為何講求覆蓋率,就是要確保可靠度是有保障的 11/22 13:04
→ acgotaku: 單元邏輯有沒有正確,只是其中之一 不是全部 11/22 13:06
請問你指的是 db in memory？
→ superpandal: CRUD是很制式化的技術應用 想方設法使程式碼簡潔且邏 11/22 21:09
→ superpandal: 輯圓融 做到這一步即便你不寫測試多半應用不會有錯 11/22 21:11
→ superpandal: 見到更多的是程式碼亂七八糟寫測試想hold住質量的... 11/22 21:12
→ superpandal: 當然已經是屎山的就冏了 11/22 21:17
→ superpandal: 別人的產品可以不必搞到這樣 但有某種程度方便很多 11/22 21:20
產品程式碼寫不好測試程式很難寫...
※ 編輯: a804372004 (114.44.115.11 臺灣), 11/23/2022 12:13:17
→ superpandal: 對 所以重點還是在於程式碼質量 寫的好不用什麼測都 11/23 21:39
→ superpandal: 大概可以知道結果 11/23 21:40
→ superpandal: 單元測試還是面向開發者 開發者可以完全控制寫單元測 11/23 21:43
→ superpandal: 試只是再驗證 11/23 21:43
→ superpandal: 而且通常不會有那麼多時間寫的 11/23 21:44