Rails 炸機實務

Rails 炸機實務如何不要炸爛你家機器和你老闆的臉

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

前言
這是在講測試的，只是順便講怎麼炸掉你家網站
在現有專案導入測試碼撰寫
使用 Rspec
使用真實範例
演講者自己也是新手
適合聽眾 :
沒寫過測試但有興趣的人
想了解測試但不知道如何下手的人
想看看別人怎麼炸他們家專案的人

關於本章要提到的測試指的是自動化測試

為什麼我要寫測試 ?

可不可以不要寫測試 ? 要如何避免炸機 ?

星期五的時候不要 Deploy Code 腦袋通常都不太清楚

網站炸掉了星期一 deploy code 後炸掉了

進化 : 星期五的時候不要 Commit Code 那可不可以也不用來上班 ?

一旦釋出程式碼，可能的話不要動他 Code freeze if possible 通常是不太可能

不得不動它的時候還是不小心炸掉了

寫的時候請小心謹慎正式的行政命令

檢查程式碼有沒有錯誤開發端要自己跑一次開瀏覽器看看有沒有問題在你每一次更改時重覆以上事項

還是炸掉網站了錯誤是在別的環節，因為這次的修改引發

在你每一次更改時重覆以上事項注意這個重覆

DRY D on't R epeat Y ourself 為什麼要堅持不寫測試啊 ?

每件事都有它的代價一個開發所需時數約 10 小時，上線 1 個月的活動網站一個開發所需時數超過 100 小時上線已經超過 2 年的專案且持續有調整與新功能的社群網

實際範例 : 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 開始寫 ( 補 ) 測　

在 2011 年 3 月開始開發在 5 月 ~6 月時連續發生慘案

慘案發生原因 : 規格
PM 是產品部門，企畫的是美妝部，開發的是技術部
PM 並非技術出身
規格時沒考慮到一些例外狀況處理
溝通不統一
開發端發現規格有問題，與企畫討論後修改了規格。但是 PM 端不知道這件事

慘案發生原因 : 時程
2011 年 3 月第一個程式碼提交， 6 月要上線
5 月加入開發，此時進度約 50%
只檢測功能正不正常，不管程式碼品質
上線後再回來修
長輩名言 : 拋掉羞恥心程式就可以寫很快了
結果來回的次數變多
驗收功能的是 PM 部，他站在你後面而且很火

慘案發生原因 : 外部網站介接
Session 與 PIXNET 本家 (PHP) 共用
使用 PIXNET 相簿作圖床 (Oauth API)
使用 PIXNET 的 Solr 作為 Search Engine
開發與檢測驗收都很費功夫

決定補測試

事前準備
選擇並學會使用你的 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

事前準備
整理並確認專案規格
企畫端寫 User Story
規格必須由開發單位撰寫，由企畫端驗收。
PM 由技術部成員擔任
測試就是一種程式規格，程式的規格就是滿足測試條件。

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! ( 作假資料與假回傳 )

測試絕大部分花費的時間是在處理這些假回傳以及準備需要的假資料

範例 : 錯誤的測試

測試碼不能檢查到程式碼的錯誤那就是沒有用的測試

補寫測試的流程
補寫 Spec Code 使測試成功
確認如果更動 Spec code 會使測試失敗
確認如果更動被測試的 code 會使測試失敗

好處
可以在不怕炸機的狀況下 Refactor 程式碼
重新確認規格與程式碼是否符合

注意事項
專注於被測試的項目，讓其他部分用假資料 (Fixture) 與假回傳 (Mock & Stub) 來處理
確保你的測試可以有用：試著”故意”寫錯程式碼讓測試失敗，藉此練習想像各種的錯誤情況，以提早預防
當局者迷，可以找另一個人幫你 Review 或 Pair Programing

測試不是萬靈丹
不用追求最完美，只要能不炸機就好
人工測試也有其優點

Ｑ＆Ａ

Rails 炸機實務

by Manic

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

Rails 炸機實務 Presentation Transcript