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