Re: [轉錄] 開發人員的測試悖論(The Developer Tes …
※ 引述《deanh (夜想者)》之銘言：
: 推 lunastorm:我最近也碰到這個問題，的確碰到db這段就是在整合測試了 05/17 10:24
: 推 Ting1024:我也碰到這問題... 05/17 20:05
: → newjoy:好吧, 那換個問法 有辦法不讓這些整合測試作廢嗎 05/17 22:07
有，就是把這些整合測試變成單元測試。
如果你的整合環境是變動大的，無法預測的，每次都有不同的驚喜的，
那我建議你不要做自動化整合測試。如果你連手動測試都沒有辦法每次
都產生一致性的結果，你應該回去看看你的Production Code有沒有問題
。
你需要去計算撰寫整合測試的投資報酬率，我有朋友告訴我，如果你的自動化整合測試
不能夠在沒有修改的狀況下使用17個Release，那麼這個自動化整合測試可能就沒有進行
的價值，因為你最終還是必須要進行手動測試，你無法相信自動化測試的結果。(雖然我
不知道這個數字是哪裡來的)
你必須先問問你自己，有沒有先做單元測試。沒有單元測試就做整合測試的話，會讓
整合測試的Case變很多，而出錯的機率也會提高很多，出錯以後，沒有單元測試的幫
忙，你必須回去看自己的單元有沒有錯。進而加長了除錯的時間。
你現在要做的，是回去把單元測試給做好，而不是投入在自動化整合測試上面。
你可以使用Test Framework裡面的Stub物件或是Mock物件去取代資料庫物件的行為
，比如說，你不需要知道資料庫插入的結果是不是在資料庫多了一行，而是要確認
當資料庫回傳True的時候，你的程式會正確往下做，而當資料庫回傳False的時候
，你的程式碼能夠抓到這個錯誤，並且做出適當的回應。
Unit Test Focus在白箱測試，希望每個判斷、迴圈跟程式碼都被執行過一遍，如果
你覺得你的Unit Test Code很難跟資料庫切開，表示你的Product Code沒寫好，
跟外部資源過度耦合，你首先要做的是Refactory你的Production Code，提高它的
Testability。
也許你可以貼上程式片段讓大家討論一下。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.166.227.62
※ 編輯: deanh 來自: 118.166.227.62 (05/17 23:49)
→
05/18 01:13, , 1F
05/18 01:13, 1F
→
05/18 01:13, , 2F
05/18 01:13, 2F
推
05/19 01:25, , 3F
05/19 01:25, 3F
→
05/19 01:25, , 4F
05/19 01:25, 4F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 6 之 8 篇)：