為什麼這篇後 端 單元測試鄉民發文收入到精華區：因為在後 端 單元測試這個討論話題中，有許多相關的文章在討論，這篇最有參考價值！作者tofuflower (無)看板Soft_Job標題Re: [請益] 測試程式問題時間Mon J...
後 端 單元測試 在 三歲看世界 Instagram 的最佳貼文
2021-07-11 09:57:58
-《軟體工程師》 👦🏻受訪者 在華航實習過目前在銀行的資訊單位工作 🎈 1. 軟體工程師的工作內容？ 主要是系統開發，有的小公司因為人力較不足可能會涵蓋系統設計、開發、維護等等工作。 _ 2. 每天的工作流程？ (1) 依照規格書(SPEC)在本機環境完成開發 (2) 過程中需要做單元測試，確保自己...
※ 引述《VFCanisLupus (CanisLupus)》之銘言：
: 請教一下版上前輩測試方面的問題
: 我們公司的產品是有著微服務架構的後端服務，最近想導入測試但是在開會時對於測試的方
: 式與方向跟夥伴們有些意見分歧，想聽聽版上前輩的意見。
: 1. 單元測試： 我的想法是單元測試是針對每個method做測試目的是希望每個method都能符
: 合預期不會改a錯b. 單元測試也不應該與外部相依，比如說資料庫應該都用mock DAO 的方
: 式來測試。
: 不過夥伴認為我們應該也要連sql都一起測試，不然我怎麼知道sql是否正確？(意見不同1)
: ，寫測試程式很容易因為測試案例不好而導致測試測的不完全，寫這測試會很沒意義（意見
: 不同2）
1. 個人偏好做法：DAO 層的任務是跟 DB 溝通，這裡的 unit test 我會測 SQL。
商務層應該只關心商務邏輯，直接 mock DAO 層。這是來自單一責任原則的啟發。
2. 你可以找一下你們使用的語言有沒有用來跑單元測試的 embeedded db/mongo/redis。
如果沒有的話可以考慮跑單元測試時用 docker 跑 db 起來測試。
3. 發現自己測試沒寫好，進而反省改善就是種意義。當然，這僅止於懂的反省自身的
工程師。
: 2. 整合測試： 老闆認為有單元測試只不過方便日後重構而已，還不如來寫整合測試（打HT
: TP request 測試） （意見不同3）
unit test 除了驗證程式行為還有其他好處：
1. 未來改邏輯或加 feature 你會比較有勇氣。你可以想像你每次想修改一段邏輯，
都要等整合測試跑個十幾分鐘才能得到反饋，是我都沒勇氣改了。
2. 好測試的 code 通常程式架構會比較好改：為了讓程式好測/可測，你會讓程式
耦合性降低，讓功能責任單一，甚至你會更明確知道 DI 的重要性。
3. 有測試的 code 等於一份該 component 的使用教學，像我就會從前人的測試 code
學業務邏輯。
4. 整合測試涵蓋範圍太廣，一個測試失敗可能是網路/系統/設定/程式碼任何一個地方
出問題；反觀單元測試執行速度快，又可以快速定位問題。好單元，不測嗎？
以上個人不負責任經驗談。
: 我的想法是
: 意見1: 可以延到整合測試測，因為單元測試目的是在於驗證程式碼有無如預期進行，且應
: 該要可以快速測試驗證。
: 意見2: 可以用測試覆蓋率為參考依據
: 意見3：因為整合測試無法有效提昇覆蓋率，且有環境等因素考量，也跟業務邏輯牽扯 （塞
: 資料順序等等），反而門檻更高。
: 不知道版上前輩有什麼其他想法嗎？
: 或者其實我觀念有錯誤？
: 謝謝
: --
: ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 27.242.203.105 (臺灣)
: ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1563110242.A.161.html
: 推 jack0204: 單元測試也能測SQL阿，有的框架支援記憶體儲存ORM 07/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
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 49.215.240.201 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1563121021.A.0F5.html
推 t64141: 想法跟你很相近推 07/15 00:56
推 anandydy529: 中肯 07/15 01:24
推 sharku: 推 07/15 11:18
推 slytb: 推 07/15 16:34
推 landlord: 說得好 07/16 01:08