Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

地獄Spec

2,133 views

Published on

地獄Spec

  1. 1. 地獄のRSpec逃げちゃだめだ、逃げちゃだめだ・・・ おおはら@Drecom Co., Ltd.
  2. 2. 警告このプレゼンを見てから7日以内にspecヲ20コGreenにしないといけません。さもなくば貴方のプロジェクトは炎上し、メンバーは疲れ果て疾走し行方不明になる可能性があります。貴方のプロジェクト、大丈夫ですか・・・?
  3. 3. 提供DRECOM RWith entertainment
  4. 4. 自己紹介おおはらつねのりアプリケーションエンジニア所属:広告事業本部twitterアカウント:@ohrdev
  5. 5. 経歴Rails歴:2年半札幌の会社からドリコムへ転職元SIer(元IT亡者)ソーシャルゲームはヤった事ない(シゴトハノゾク)
  6. 6. 今日のおはなし
  7. 7. テスト
  8. 8. RSpec
  9. 9. 質問1spec
  10. 10. 何 緑時赤 最 初気。 。
  11. 11. グリーン維持は大変
  12. 12. 質問2グリーン維持してる?
  13. 13. 理想的なプロジェクトなら・・・
  14. 14. だが現実はキビシイ・・・
  15. 15. 現実
  16. 16. うちのシステムでRSPEC導入した時の話
  17. 17. 組織(広告事業部) 企画 営業 開発 受注クライアント カスタマー サポート
  18. 18. サービス(poncan)ソーシャルアプリ向けリワード広告サービスhttp://www.slideshare.net/CyLab/poncan2リワード広告とは:ユーザーに広告を提供し、その成果に対して一定の報酬(ポイント等)を支払うサービス
  19. 19. システム(poncan)Rails2.3.8 + passengerRuby1.8.7MySQL5Memcached(acts_as_cached)Resque/Redis
  20. 20. 運用止めれない(サーバー停止のメンテは基本なし)Migrationは使用しない(できない)→openark kit/oak-online-alter-table(1日のリリース:2.1回)(1日コミット数:22.3回)(毎日リリース・毎週機能追加・拡張)
  21. 21. 背景テストコード(メンテされて)なかったリリースまでに(チェックで)時間かかる漏れや事故が多い
  22. 22. バグ 事故 漏れ poncan 安心感 テストコード(のメンテ)不足
  23. 23. Specを書けよデコ助野郎!
  24. 24. RSpec 開発メンバー
  25. 25. ①導入前の状態有効なRSpecほぼ無し自動生成されたtestunitが少々誰も動かしていない当然メンテもしていない
  26. 26. ②導入直後にやった事メンテされていないテストコードは削除 -流用できないコード多数 -そもそも仕様が既に変わっている自動生成されたコードも削除テスト用データ -fixturesからFactoryGirlに移行
  27. 27. ②失敗・教訓(導入直後)とりあえず動くだけでは不十分 -実行時間が長いと流さなくなる自動で動かさないと忘れる -autotest使うようにしたテストデータを全てFactoryGirlで賄うのは面倒 -マスタデータはfixtures -トランザクションデータはFactoryGirl
  28. 28. ③しばらく経って(1週間位)やった事Specを書く対象を絞った -まずはmodelから書いていく事にした -controllerは後回し
  29. 29. ③失敗・教訓(しばらく経って)ビジネスロジック部分をspecの対象にすべきだった -modelだけでは不十分で、(Fat)controller のロジック部分も対象にしないと無意味万遍なくspecを書こうとして途方に暮れた -全部書く時間ない・モチベーション下がる -修正の入った箇所から充実させていった
  30. 30. ④慣れてきた頃(1ヶ月位)にやった事CIを導入した -手軽なBigTunaを採用遅い処理の改善 -テストダブル(モック・スタブ)に置き換え -migrationからschema.rb読み込みに変更
  31. 31. ④失敗・教訓(慣れてきた頃)CIの失敗通知が続いてREDに慣れてしまった -失敗だけでなく失敗数も通知するようにした -オールグリーンを目標に設定 -だんだんREDが減っていくのを見てモチベ△メンバー間のspecの書き方に統一性が無くなってきた -勉強会・共有会で書き方をある程度共有 -THE RSPEC BOOK
  32. 32. ⑤充実してきた頃(3ヶ月位)にやった事カバレッジを指標にした -rake spec:rcovテストデータの整理 -モデル(テーブル)数80くらい
  33. 33. ⑤失敗・教訓(充実してきた頃)カバレッジは万能じゃない -「レガシーコード=テストの無いコード」なので意 味はあるが・・・ -Reekを取るようにした(お手軽/ReekViewer)  https://github.com/Shinya131/reekviewerFactoryGirlがパンクした -factory.rbに全てぶっ込むのではなく、 factoriesフォルダ以下にファイル分割配置 -リレーション指定やりすぎると破綻(メンテ不能)に
  34. 34. ⑥グリーンになって(5ヶ月位)にやった事trunkとbranchに対してそれぞれCIを回した -管理・配信・配信(mixi特化)アプリごとに、そ れぞれ計6つのCIを回す -trunkとbranchの差分を全てチェック(苦行)レッドからグリーンにするではなく、グリーンを維持する ように目標をシフト
  35. 35. ⑥失敗・教訓(グリーンになって)Trunkはグリーンだけど、branchはレッドという状況に -息の長いbranchだと未マージ・マージ漏れが 発生しうる -特定のコードをbranchにマージする・しないで赤 だったり緑だったりするケースがあるなるべくtrunkとbranchの差分を小さくするように意 識
  36. 36. ⑦そして今に至る・・・ ビフォー
  37. 37. ⑦そして今に至る・・・アフター
  38. 38. 結果どうなった?リリース頻度が加速 -漏れ・事故が少なくなった -即リリース・即bug発見・即修正・即リリース・・・“ある程度”安心できるtrunkとbrunchの差分が減った100%bug潰すのは無理だけど、即発見・修正はでき る
  39. 39. 今後Rails2.3.8から、Rails3.xにVerUp -Jenkins + rvm + rails3.x でCI回すもうなにも怖くない(CIまわしてればある程度)Seleniumで面もチェック -目確認は(最低限しか)したくない引き続きGREEN維持
  40. 40. まとめRSpecちゃんとしたら、リリース頻度あがったSpecメンテ => CI導入 じゃなくて、CI導入 => Specメンテ ってするとウマく回ったBUG潰し・予防よりもBUGの早期発見・早期修正に役 立ったBUGは出る時は出る、Rspec/CIは万能じゃないの で注意
  41. 41. ドリコムメンバー募集ドリコム広告事業本部では、テスト好きなメンバーを 募集しています。http://www.drecom.co.jp/recruit/

×