看板
[ Soft_Job ]
討論串開發人員的測試悖論(The Developer Tes …
共 8 篇文章
內容預覽:
以前我的 team. 在推 cppunit 時遇到很多阻礙. 簡單的說就是........RD 想偷懶. 很多member 跟會跟我 complain 說. 程式寫完自己都會做 test. 幹麻搞得這麼麻煩. 我總是不厭其煩的說. 這份code不會永遠只在你手上做 maintain. 請替你後續接手
(還有13個字)
內容預覽:
不是。. 這可以讓你第一次寫程式的時候，減少Bug。. 為什麼會減少Bug呢？因為他把該用單元測試Framework進行的工作，用Manual的方式. 做掉了。. 單元測試並不僅止於寫Code來進行測試。這也是單元測試的方法，只是用Manual. 的方式來做。. 動態更改變數跑不同流程，其實就是在跑
(還有699個字)
內容預覽:
有，就是把這些整合測試變成單元測試。. 如果你的整合環境是變動大的，無法預測的，每次都有不同的驚喜的，. 那我建議你不要做自動化整合測試。如果你連手動測試都沒有辦法每次. 都產生一致性的結果，你應該回去看看你的Production Code有沒有問題. 。. 你需要去計算撰寫整合測試的投資報酬率，我
(還有553個字)
內容預覽:
由另一些角度來看看.... 我會認為Programmer一般都是寫出認為是正確的code, 想沒有任何因由. 的事況下debug會因為看不到自己的盲點而看不到成效. 這和要求撰稿人. 自行proofread的效果不會有很大分別.. 因此如果自己寫test case然後以此為據寫code, 即使all
(還有512個字)
內容預覽:
你完全弄錯了。. Mock Object在單元測試裡面不是拿來給你這樣用的。. Unit Test測試的目的是你的Code，不是你的Database跟Table。. 所以你的資料複雜，db複雜，在哪裡，有幾千個Table都不是重點。. Mock Object更不會有「產生一筆測試資料，可能就比寫整個
(還有102個字)