Rails 炸機實務
- 1. Rails 炸機實務 如何不要炸爛你家機器 和你老闆的臉
- 2. About Me Manic Chuang http://tech.manic.tw http://www.manic.tw PIXNET (2008~), PHP Programer Half Rails Developer since 2009 PIXNET Rails Team in 2011, April
- 3. 前言 這是在講測試的， 只是順便講怎麼炸掉你家網站 在現有專案導入測試碼撰寫 使用 Rspec 使用真實範例 演講者自己也是新手 適合聽眾 : 沒寫過測試但有興趣的人 想了解測試但不知道如何下手的人 想看看別人怎麼炸他們家專案的人
- 5. 為什麼我要寫測試 ?
- 6. 可不可以不要寫測試 ? 要如何避免炸機 ?
- 7. 星期五的時候不要 Deploy Code 腦袋通常都不太清楚
- 8. 網站炸掉了 星期一 deploy code 後炸掉了
- 9. 進化 : 星期五的時候不要 Commit Code 那可不可以也不用來上班 ?
- 10. 一旦釋出程式碼， 可能的話不要動他 Code freeze if possible 通常是不太可能
- 13. 檢查程式碼有沒有錯誤 開發端要自己跑一次 開瀏覽器看看有沒有問題 在你每一次更改時 重覆以上事項
- 17. DRY D on't R epeat Y ourself 為什麼要堅持不寫測試啊 ?
- 18. 每件事都有它的代價 一個開發所需時數約 10 小時， 上線 1 個月的活動網站 一個開發所需時數超過 100 小時 上線已經超過 2 年的專案 且持續有調整與新功能的社群網
- 19. 實際範例 : PIXNET 化妝台 暱稱 Pixlovely http://channel.pixnet.net/lovely 歷經三版本 PHP 時代 : http://channel.pixnet.net/lovely ??? ~ 2009.07 Rails 2.3.4 版本 http://belovely.tw 2009.07 ~ 2011.06 Rails 3 版本 http://channel.pixnet.net/lovely 2011.06 ~ 2011.07 開始寫 ( 補 ) 測
- 20. 在 2011 年 3 月開始開發 在 5 月 ~6 月時連續發生慘案
- 21. 慘案發生原因 : 規格 PM 是產品部門，企畫的是美妝部， 開發的是技術部 PM 並非技術出身 規格時沒考慮到一些例外狀況處理 溝通不統一 開發端發現規格有問題， 與企畫討論後修改了規格。 但是 PM 端不知道這件事
- 22. 慘案發生原因 : 時程 2011 年 3 月第一個程式碼提交， 6 月要上線 5 月加入開發，此時進度約 50% 只檢測功能正不正常，不管程式碼品質 上線後再回來修 長輩名言 : 拋掉羞恥心程式就可以寫很快了 結果來回的次數變多 驗收功能的是 PM 部，他站在你後面而且很火
- 23. 慘案發生原因 : 外部網站介接 Session 與 PIXNET 本家 (PHP) 共用 使用 PIXNET 相簿作圖床 (Oauth API) 使用 PIXNET 的 Solr 作為 Search Engine 開發與檢測驗收都很費功夫
- 24. 決定補測試
- 25. 事前準備 選擇並學會使用你的 Test Framework 在此使用 RSpec Rails 清單 http://ihower.tw/rails3/testing.html http://www.slideshare.net/ihower/rspec-7394497 http://pragprog.com/book/achbd/the-rspec-book
- 26. 事前準備 整理並確認專案規格 企畫端寫 User Story 規格必須由開發單位撰寫，由企畫端驗收。 PM 由技術部成員擔任 測試就是一種程式規格， 程式的規格就是滿足測試條件。
- 27. Rspec-Rails 和 Rails 一樣依照 MVC 架構分別有 Model, View, Controller Integration Test: Request specs 其他 : Route specs, Helper specs
- 30. 進一步整理 未登入前會看到登入資訊 登入後會看到自己的暱稱 (PIXNET) 與三個管理連結 登入後如果有未回覆的玩試用 ( 問卷 ) 會顯示通知
- 33. Failed
- 35. Fake It! ( 作假資料與假回傳 )
- 36. 測試絕大部分花費的時間 是在處理這些假回傳 以及準備需要的假資料
- 39. 範例 : 錯誤的測試
- 41. 補寫測試的流程 補寫 Spec Code 使測試成功 確認如果更動 Spec code 會使測試失敗 確認如果更動被測試的 code 會使測試失敗
- 42. 好處 可以在不怕炸機的狀況下 Refactor 程式碼 重新確認規格與程式碼是否符合
- 43. 注意事項 專注於被測試的項目，讓其他部分用 假資料 (Fixture) 與假回傳 (Mock & Stub) 來處理 確保你的測試可以有用： 試著”故意”寫錯程式碼讓測試失敗， 藉此練習想像各種的錯誤情況，以提早預防 當局者迷，可以找另一個人幫你 Review 或 Pair Programing
- 45. Ｑ＆Ａ