Rails 炸機實務 如何不要炸爛你家機器 和你老闆的臉
About Me <ul><ul><li>Manic Chuang </li></ul></ul><ul><ul><ul><li>http://tech.manic.tw </li></ul></ul></ul><ul><ul><ul><li>...
前言 <ul><ul><li>這是在講測試的, 只是順便講怎麼炸掉你家網站 </li></ul></ul><ul><ul><li>在現有專案導入測試碼撰寫 </li></ul></ul><ul><ul><li>使用  Rspec </li></...
關於本章要提到的測試 指的是自動化測試
為什麼我要寫測試 ?
可不可以不要寫測試 ? 要如何避免炸機 ?
星期五的時候不要  Deploy Code 腦袋通常都不太清楚
網站炸掉了 星期一  deploy code  後炸掉了
進化 : 星期五的時候不要 Commit Code 那可不可以也不用來上班 ?
一旦釋出程式碼, 可能的話不要動他 Code freeze if possible 通常是不太可能
不得不動它的時候 還是不小心炸掉了  
寫的時候請小心謹慎 正式的行政命令
檢查程式碼有沒有錯誤 開發端要自己跑一次 開瀏覽器看看有沒有問題 在你每一次更改時 重覆以上事項
還是炸掉網站了 錯誤是在別的環節, 因為這次的修改引發
 
在你每一次更改時 重覆以上事項 注意這個重覆
DRY D on't  R epeat  Y ourself 為什麼要堅持不寫測試啊 ?
每件事都有它的代價 一個開發所需時數約 10 小時, 上線 1 個月的活動網站 一個開發所需時數超過 100 小時 上線已經超過 2 年的專案 且持續有調整與新功能的社群網
實際範例 : PIXNET  化妝台 <ul><ul><li>暱稱  Pixlovely </li></ul></ul><ul><ul><li>http://channel.pixnet.net/lovely </li></ul></ul><u...
在 2011 年 3 月開始開發 在 5 月 ~6 月時連續發生慘案
慘案發生原因 :  規格 <ul><ul><li>PM 是產品部門,企畫的是美妝部, 開發的是技術部 </li></ul></ul><ul><ul><ul><li>PM 並非技術出身 </li></ul></ul></ul><ul><ul><u...
慘案發生原因 :  時程 <ul><ul><li>2011 年 3 月第一個程式碼提交, 6 月要上線 </li></ul></ul><ul><ul><li>5 月加入開發,此時進度約 50% </li></ul></ul><ul><ul><l...
慘案發生原因 :  外部網站介接 <ul><ul><li>Session  與  PIXNET  本家 (PHP)  共用 </li></ul></ul><ul><ul><li>使用  PIXNET  相簿作圖床  (Oauth API) </...
決定補測試
事前準備 <ul><ul><li>選擇並學會使用你的  Test Framework </li></ul></ul><ul><ul><ul><li>在此使用   RSpec Rails </li></ul></ul></ul><ul><ul><...
事前準備 <ul><ul><li>整理並確認專案規格 </li></ul></ul><ul><ul><ul><li>企畫端寫  User Story </li></ul></ul></ul><ul><ul><ul><li>規格必須由開發單位撰寫...
Rspec-Rails <ul><ul><li>和  Rails  一樣依照  MVC  架構分別有  Model, View, Controller  </li></ul></ul><ul><ul><li>Integration Test: ...
 
 
進一步整理 <ul><ul><li>未登入前會看到登入資訊 </li></ul></ul><ul><ul><li>登入後會看到自己的暱稱 (PIXNET) 與三個管理連結 </li></ul></ul><ul><ul><li>登入後如果有未回覆...
因為是事後補測試 <ul><li>layouts/application.html.erb </li></ul>針對對應的程式碼來寫測試
寫出相對應的測試碼 <ul><li>spec/views/layouts/application.html.erb_spec.rb </li></ul>
Failed
錯誤的部分與測試內容沒關係 那不重要 !
Fake It! ( 作假資料與假回傳 )
  測試絕大部分花費的時間 是在處理這些假回傳 以及準備需要的假資料
 
 
範例 :  錯誤的測試
測試碼不能檢查到 程式碼的錯誤 那就是沒有用的測試
補寫測試的流程 <ul><ul><li>補寫  Spec Code  使測試成功 </li></ul></ul><ul><ul><li>確認如果更動  Spec code  會使測試失敗 </li></ul></ul><ul><ul><li>確...
好處 <ul><ul><li>可以在不怕炸機的狀況下  Refactor  程式碼 </li></ul></ul><ul><ul><li>重新確認規格與程式碼是否符合 </li></ul></ul>
注意事項 <ul><ul><li>專注於被測試的項目,讓其他部分用 假資料 (Fixture) 與假回傳 (Mock & Stub) 來處理 </li></ul></ul><ul><ul><li>確保你的測試可以有用: 試著”故意”寫錯程式碼讓...
測試不是萬靈丹 <ul><ul><li>不用追求最完美,只要能不炸機就好 </li></ul></ul><ul><ul><li>人工測試也有其優點 </li></ul></ul>
Q&A  
Upcoming SlideShare
Loading in...5
×

Rails 炸機實務

2,080

Published on

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,080
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
31
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Rails 炸機實務

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

    Clipping is a handy way to collect important slides you want to go back to later.

×