※ 引述《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：因為整合測試無法有效提昇覆蓋率，且有環境等因素考量，也跟業務邏輯牽扯 （塞
: 資料順序等等），反而門檻更高。
: 不知道版上前輩有什麼其他想法嗎？
: 或者其實我觀念有錯誤？
: 謝謝
: