地獄Spec
Upcoming SlideShare
Loading in...5
×
 

地獄Spec

on

  • 1,635 views

 

Statistics

Views

Total Views
1,635
Views on SlideShare
1,635
Embed Views
0

Actions

Likes
8
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

地獄Spec 地獄Spec Presentation Transcript

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