推 Ting1024:瞭解了。看來寫軟體很辛苦阿... 05/17 23:54
→ Ting1024:希望d大多多分享一些資源 :) 05/17 23:55
→ deanh:看The Art of Unit Test，可以學到很多喔！開發人員必看 05/17 23:58
推 Ting1024:收到 XD 05/18 00:03
推 atst2:推這篇 05/18 00:59
※ 引述《Ting1024 (無)》之銘言：
: ※ 引述《bravomao (資訊苦力)》之銘言：
: : 小弟斗膽分享一下個人的經驗。
: : 通常我們在開發時期多少會對自己所寫的程式進行單元測試，其實這階段的測試充其量
: : 也只能測試出元件的邏輯流程是否正確，如果這階段的測試都無法通過，這個程式根本
: : 就是無法提交的。
: 像我同事他就是這樣除錯的
: 寫一段程式, 編譯成功 -> 設中斷點 ->執行
: -> 動態更改變數跑不同流程 -> 把分支都跑過一次
: -> 繼續寫下一段小程式
: 看他的程式幾乎都是 0 bug... 是不是這樣的方式是最好的?
不是。
這可以讓你第一次寫程式的時候，減少Bug。
為什麼會減少Bug呢？因為他把該用單元測試Framework進行的工作，用Manual的方式
做掉了。
單元測試並不僅止於寫Code來進行測試。這也是單元測試的方法，只是用Manual
的方式來做。
動態更改變數跑不同流程，其實就是在跑不同的Test Case，改變變數，其實就是改變
函數的輸入或是使用Stub/Mock物件。
他是在做單元測試。一次性的單元測試。
單元測試的目的並不是這麼簡單，單元測試還有另外幾項重要用途：
1.Refactory的基礎：沒有人可以說自己的程式碼寫出一次就會100%完美，沒有人說
自己寫出的程式碼可以應付所有的需求變動，更沒有人可以保證自己的Code在跟
別人的物件整合的時候沒有Bug。當你需要Refactory舊有程式碼的時候，有完整
的單元測試，可以讓回歸測試的時間縮短，可以讓你還有接手你程式修改的人更有
信心，可以讓這些原有的Code不會變成Lagacy。
請問你慢慢Debug，跑完一次測試要多久？
2.可以提前完成物件：使用Unit Test Framework中的Stub還有Mock方法可以模擬單元
其他物件之間互動的過程，在其他物件都還沒有完成的的狀況下，我就可以依據Spec
將程式開發完成，無需依賴其他物件。也降低了整合測試的成本。
3.好的Unit Test Code可以當成API Document：注意，我說的是高可讀性、可信、並且
高維護性的單元測試程式碼可以當成一個很好的API Document。有興趣的可以翻一下
很多Open Source Package的單元測試程式碼，像是PHP、Doctrine、Spring等等的
單元測試程式碼，特別是在多人開發的Open Source環境，保證程式碼的品質最基礎的
方法就是有高品質的單元測試程式碼！
請這位同事好好考慮其他人，以及整體專案的未來。
如果他是寫個自己要用的AP或是要寫個APP上傳到Apple Store上面，倒是沒有什麼關係。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.166.227.62
※ 編輯: deanh 來自: 118.166.227.62 (05/17 23:50)