Rails 炸機實務

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

測試不是萬靈丹

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

Ｑ＆Ａ