PTT職涯區 / Soft_Job (軟體人)

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

看板Soft_Job (軟體人)作者 (忽冷忽熱摸不著)時間1年前 (2022/11/20 01:46), 1年前編輯推噓3(3推 0噓 30→)
留言33則, 7人參與, 1年前最新討論串1/3 (看更多)
將單元測試實作於專案時，發現絕大部分API都是針對資料庫做CRUD，這部分程式透過in memory 寫了整合測試，越寫越覺得不對勁，心想單元測試數量不是應該要最多？ 網路文 章、影片或實體書籍大多也在探討如何寫單元測試，整合測試資源相對少，在想是不是我 哪裡做錯了，懇請各位大神指教。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 39.9.229.151 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1668880017.A.B02.html
→
11/20 01:57, 1年前 , 1F
以傳統三層式架構來說我多半是測中間的商業邏輯層
11/20 01:57, 1F
單元測試確實是測商業邏輯的部份，我的專案含有商業邏輯的程式不多，變成都在寫整合測試
推
11/20 02:43, 1年前 , 2F
看情況，只要整合測試寫/改起來不累，單元測試就沒那麼重要
11/20 02:43, 2F
推
11/20 02:49, 1年前 , 3F
數量差距不用太在意，只要好寫又有效，多一點無妨
11/20 02:49, 3F
→
11/20 11:41, 1年前 , 4F
實務上，單元測試不是看數量多少，是看覆蓋率。整合測試不
11/20 11:41, 4F
→
11/20 11:41, 1年前 , 5F
是工程師在開發環境寫單元測試，而是在測試環境，QA寫。
11/20 11:41, 5F
→
11/20 11:42, 1年前 , 6F
簡單說，從來不追求數量。追求覆蓋。
11/20 11:42, 6F
了解，爬文看到測試金字塔提到層次越高的測試應該會越少，所以才想是否寫錯了，另外，公司目前沒有QA，所有測試都是工程師寫
→
11/20 18:02, 1年前 , 7F
小公司不會有賠錢部門QA的
11/20 18:02, 7F
推
11/21 15:56, 1年前 , 8F
不用在意數量多寡 測試數量會根據你做的架構或軟體類型變
11/21 15:56, 8F
→
11/21 15:57, 1年前 , 9F
化是很正常的一件事 像你說你API都CRUD 那當然單元測試就
11/21 15:57, 9F
→
11/21 15:57, 1年前 , 10F
都通常在測處理資料的商業邏輯 但要是那些邏輯也沒啥好測
11/21 15:57, 10F
→
11/21 15:58, 1年前 , 11F
就甭測了 因為本來就沒啥好測 但如果你是做個圖像引擎之類
11/21 15:58, 11F
→
11/21 15:58, 1年前 , 12F
的東西 單元測試就會變得比較多 因為運算也比較多 合理吧
11/21 15:58, 12F
我目前的情況就是這樣，運算的商業邏輯不多，API CRUD 寫整合測試就會比單元測試還多。
→
11/21 19:34, 1年前 , 13F
當然是直接整合測試就好 專案失控才要整天搞單元測試
11/21 19:34, 13F
→
11/21 19:36, 1年前 , 14F
而且ide可以單步除錯 真的要測也不用annotation的爛
11/21 19:36, 14F
→
11/21 19:36, 1年前 , 15F
方式
11/21 19:36, 15F
→
11/21 19:37, 1年前 , 16F
一勞永逸讓專案可控才是最佳品質保證
11/21 19:37, 16F
→
11/22 10:57, 1年前 , 17F
你寫db/cache用DI寫 可以很方便的 mock 這些依賴
11/22 10:57, 17F
→
11/22 10:59, 1年前 , 18F
但是也有不少做法是在測試時 用你的 db entity 真實建
11/22 10:59, 18F
→
11/22 11:00, 1年前 , 19F
一個db 在緩存中, 這樣測試有一個優點 就是確保你entity
11/22 11:00, 19F
→
11/22 11:00, 1年前 , 20F
是正確的,也可以符合你實際連線的狀況 缺點就是麻煩
11/22 11:00, 20F
→
11/22 13:02, 1年前 , 21F
上面有說CRUD邏輯簡單就不用單元測試,這是很嚴重的錯誤
11/22 13:02, 21F
→
11/22 13:04, 1年前 , 22F
單元測試為何講求覆蓋率,就是要確保可靠度是有保障的
11/22 13:04, 22F
→
11/22 13:06, 1年前 , 23F
單元邏輯有沒有正確,只是其中之一 不是全部
11/22 13:06, 23F
請問你指的是 db in memory？
→
11/22 21:09, 1年前 , 24F
CRUD是很制式化的技術應用 想方設法使程式碼簡潔且邏
11/22 21:09, 24F
→
11/22 21:11, 1年前 , 25F
輯圓融 做到這一步即便你不寫測試多半應用不會有錯
11/22 21:11, 25F
→
11/22 21:12, 1年前 , 26F
見到更多的是程式碼亂七八糟寫測試想hold住質量的...
11/22 21:12, 26F
→
11/22 21:17, 1年前 , 27F
當然已經是屎山的就冏了
11/22 21:17, 27F
→
11/22 21:20, 1年前 , 28F
別人的產品可以不必搞到這樣 但有某種程度方便很多
11/22 21:20, 28F
產品程式碼寫不好測試程式很難寫... ※ 編輯: a804372004 (114.44.115.11 臺灣), 11/23/2022 12:13:17
→
11/23 21:39, 1年前 , 29F
對 所以重點還是在於程式碼質量 寫的好不用什麼測都
11/23 21:39, 29F
→
11/23 21:40, 1年前 , 30F
大概可以知道結果
11/23 21:40, 30F
→
11/23 21:43, 1年前 , 31F
單元測試還是面向開發者 開發者可以完全控制寫單元測
11/23 21:43, 31F
→
11/23 21:43, 1年前 , 32F
試只是再驗證
11/23 21:43, 32F
→
11/23 21:44, 1年前 , 33F
而且通常不會有那麼多時間寫的
11/23 21:44, 33F
‣ 更多 a804372004 的文章
文章代碼(AID): #1ZUHQHi2 (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 a804372004 的文章
文章代碼(AID): #1ZUHQHi2 (Soft_Job)