Rails 炸機實務

  • 2,000 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,000
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
30
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
      • 使用真實範例
      • 演講者自己也是新手
      • 適合聽眾 :
        • 沒寫過測試但有興趣的人
        • 想了解測試但不知道如何下手的人
        • 想看看別人怎麼炸他們家專案的人
  • 4. 關於本章要提到的測試 指的是自動化測試
  • 5. 為什麼我要寫測試 ?
  • 6. 可不可以不要寫測試 ? 要如何避免炸機 ?
  • 7. 星期五的時候不要 Deploy Code 腦袋通常都不太清楚
  • 8. 網站炸掉了 星期一 deploy code 後炸掉了
  • 9. 進化 : 星期五的時候不要 Commit Code 那可不可以也不用來上班 ?
  • 10. 一旦釋出程式碼, 可能的話不要動他 Code freeze if possible 通常是不太可能
  • 11. 不得不動它的時候 還是不小心炸掉了  
  • 12. 寫的時候請小心謹慎 正式的行政命令
  • 13. 檢查程式碼有沒有錯誤 開發端要自己跑一次 開瀏覽器看看有沒有問題 在你每一次更改時 重覆以上事項
  • 14. 還是炸掉網站了 錯誤是在別的環節, 因為這次的修改引發
  • 15.  
  • 16. 在你每一次更改時 重覆以上事項 注意這個重覆
  • 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
  • 28.  
  • 29.  
  • 30. 進一步整理
      • 未登入前會看到登入資訊
      • 登入後會看到自己的暱稱 (PIXNET) 與三個管理連結
      • 登入後如果有未回覆的玩試用 ( 問卷 ) 會顯示通知
  • 31. 因為是事後補測試
    • layouts/application.html.erb
    針對對應的程式碼來寫測試
  • 32. 寫出相對應的測試碼
    • spec/views/layouts/application.html.erb_spec.rb
  • 33. Failed
  • 34. 錯誤的部分與測試內容沒關係 那不重要 !
  • 35. Fake It! ( 作假資料與假回傳 )
  • 36.   測試絕大部分花費的時間 是在處理這些假回傳 以及準備需要的假資料
  • 37.  
  • 38.  
  • 39. 範例 : 錯誤的測試
  • 40. 測試碼不能檢查到 程式碼的錯誤 那就是沒有用的測試
  • 41. 補寫測試的流程
      • 補寫 Spec Code 使測試成功
      • 確認如果更動 Spec code 會使測試失敗
      • 確認如果更動被測試的 code 會使測試失敗 
  • 42. 好處
      • 可以在不怕炸機的狀況下 Refactor 程式碼
      • 重新確認規格與程式碼是否符合
  • 43. 注意事項
      • 專注於被測試的項目,讓其他部分用 假資料 (Fixture) 與假回傳 (Mock & Stub) 來處理
      • 確保你的測試可以有用: 試著”故意”寫錯程式碼讓測試失敗, 藉此練習想像各種的錯誤情況,以提早預防
      • 當局者迷,可以找另一個人幫你 Review 或 Pair Programing
  • 44. 測試不是萬靈丹
      • 不用追求最完美,只要能不炸機就好
      • 人工測試也有其優點
  • 45. Q&A