Railsだったり勉強会 地獄のRspec

1. 地獄の
RSpec
逃げちゃだめだ、逃げちゃだめだ・・・
おおはら@Drecom Co., Ltd.

2. 警告
このプレゼンを見てから7日以内にspecヲ
20ｺGreenにしないといけません。さもなくば
貴方のプロジェクトは炎上し、メンバーは
疲れ果て疾走し行方不明になる可能性
があります。
貴方のプロジェクト、大丈夫ですか・・・?

3. 提供
DRECOM
R
With entertainment

4. 自己紹介
おおはらつねのり
アプリケーションエンジニア
所属：広告事業本部
twitterアカウント:@ohrdev

5. 経歴
Rails歴:2年半
札幌の会社からドリコムへ転職
元SIer（元IT亡者）
ソーシャルゲームはヤった事ない（シゴトﾊノゾク)

7. 今日の
おはなし

8. テスト

9. RSpec

10. 質問１
spec

11. 何 緑
時
赤
最
初
気
。
。

12. グリーン維
持は大変

13. 質問２
グリーン維
持してる？

14. 理想的な
プロジェクト
なら・・・

16. だが現実は
キビシイ・・・

18. 現実

20. うちのシステ
ムでRSPEC導
入した時の話

21. 組織（広告事業部）
企画
営業
開発
受注
クライアント
カスタマー
サポート

22. サービス(poncan)
ソーシャルアプリ向けリワード広告サービス
http://www.slideshare.net/CyLab/poncan2
リワード広告とは：
ユーザーに広告を提供し、その成果に対して
一定の報酬（ポイント等）を支払うサービス

23. システム(poncan)
Rails2.3.8 + passenger
Ruby1.8.7
MySQL5
Memcached(acts_as_cached)
Resque/Redis

24. 運用
止めれない(サーバー停止のメンテは基本なし）
Migrationは使用しない（できない）
→openark kit/oak-online-alter-table
(1日のリリース：２．１回)
(1日コミット数：２２．３回)
(毎日リリース・毎週機能追加・拡張)

25. 背景
テストコード（メンテされて）なかった
リリースまでに（チェックで）時間かかる
漏れや事故が多い

26. バグ 事故
漏れ
poncan
安心感
テストコード(のメンテ)不足

28. Specを書けよ
デコ助野郎！

29. RSpec
開発メンバー

30. ①導入前の状態
有効なRSpecほぼ無し
自動生成されたtestunitが少々
誰も動かしていない
当然メンテもしていない

31. ②導入直後にやった事
メンテされていないテストコードは削除
-流用できないコード多数
-そもそも仕様が既に変わっている
自動生成されたコードも削除
テスト用データ
-fixturesからFactoryGirlに移行

32. ②失敗・教訓（導入直後）
とりあえず動くだけでは不十分
-実行時間が長いと流さなくなる
自動で動かさないと忘れる
-autotest使うようにした
テストデータを全てFactoryGirlで賄うのは面倒
-マスタデータはfixtures
-トランザクションデータはFactoryGirl

33. ③しばらく経って（１週間位）やった事
Specを書く対象を絞った
-まずはmodelから書いていく事にした
-controllerは後回し

34. ③失敗・教訓（しばらく経って）
ビジネスロジック部分をspecの対象にすべきだった
-modelだけでは不十分で、(Fat)controller
のロジック部分も対象にしないと無意味
万遍なくspecを書こうとして途方に暮れた
-全部書く時間ない・モチベーション下がる
-修正の入った箇所から充実させていった

35. ④慣れてきた頃（１ヶ月位）にやった事
CIを導入した
-手軽なBigTunaを採用
遅い処理の改善
-テストダブル（モック・スタブ）に置き換え
-migrationからschema.rb読み込みに変更

36. ④失敗・教訓（慣れてきた頃）
CIの失敗通知が続いてREDに慣れてしまった
-失敗だけでなく失敗数も通知するようにした
-オールグリーンを目標に設定
-だんだんREDが減っていくのを見てモチベ△
メンバー間のspecの書き方に統一性が無くなってきた
-勉強会・共有会で書き方をある程度共有
-THE RSPEC BOOK

37. ⑤充実してきた頃（３ヶ月位）にやった事
カバレッジを指標にした
-rake spec:rcov
テストデータの整理
-モデル（テーブル）数８０くらい

38. ⑤失敗・教訓（充実してきた頃）
カバレッジは万能じゃない
-「レガシーコード=テストの無いコード」なので意
味はあるが・・・
-Reekを取るようにした（お手軽/ReekViewer）
https://github.com/Shinya131/reekviewer
FactoryGirlがパンクした
-factory.rbに全てぶっ込むのではなく、
factoriesフォルダ以下にファイル分割配置
-リレーション指定やりすぎると破綻（メンテ不能）に

39. ⑥グリーンになって（５ヶ月位）にやった事
trunkとbranchに対してそれぞれCIを回した
-管理・配信・配信(mixi特化)アプリごとに、そ
れぞれ計６つのCIを回す
-trunkとbranchの差分を全てチェック（苦行）
レッドからグリーンにするではなく、グリーンを維持する
ように目標をシフト

40. ⑥失敗・教訓（グリーンになって）
Trunkはグリーンだけど、branchはレッドという状況に
-息の長いbranchだと未マージ・マージ漏れが
発生しうる
-特定のコードをbranchにマージする・しないで赤
だったり緑だったりするケースがある
なるべくtrunkとbranchの差分を小さくするように意
識

41. ⑦そして今に至る・・・
ビフォー

42. ⑦そして今に至る・・・
アフター

43. 結果どうなった？
リリース頻度が加速
-漏れ・事故が少なくなった
-即リリース・即bug発見・即修正・即リリース・・・
“ある程度”安心できる
trunkとbrunchの差分が減った
100%bug潰すのは無理だけど、即発見・修正はでき
る

44. 今後
Rails2.3.8から、Rails3.xにVerUp
-Jenkins + rvm + rails3.x でCI回す
もうなにも怖くない（CIまわしてればある程度)
Seleniumで面もチェック
-目確認は(最低限しか)したくない
引き続きGREEN維持

45. まとめ
RSpecちゃんとしたら、リリース頻度あがった
Specメンテ => CI導入 じゃなくて、
CI導入 => Specメンテ ってするとウマく回った
BUG潰し・予防よりもBUGの早期発見・早期修正に役
立った
BUGは出る時は出る、Rspec/CIは万能じゃないの
で注意

46. ドリコムメンバー募集
ドリコム広告事業本部では、テスト好きなメンバーを
募集しています。
http://www.drecom.co.jp/recruit/