地獄Spec

1,674 views
1,600 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/

×