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

地獄Spec

on

  • 1,609 views

 

Statistics

Views

Total Views
1,609
Slideshare-icon Views on SlideShare
1,609
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/