地獄のRSpec

おおはら@Drecom Co., Ltd.

逃げちゃだめだ、逃げちゃだめだ・・・

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

貴方のプロジェクト、大丈夫ですか・・・?

提供

DRECOMWith entertainment

R

自己紹介

おおはらつねのり

アプリケーションエンジニア

所属：広告事業本部

twitterアカウント:@ohrdev

経歴

Rails歴:2年半

札幌の会社からドリコムへ転職

元SIer（元IT亡者）

ソーシャルゲームはヤった事ない（シゴトﾊノゾク)

今日のおはなし

テスト

RSpec

質問１

spec

緑

最初

。 何時

赤

気

。

グリーン維持は大変

質問２

グリーン維持してる？

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

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

現実

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

組織（広告事業部）

開発

営業 企画

カスタマーサポート

受注

クライアント

サービス(poncan)

ソーシャルアプリ向けリワード広告サービス

http://www.slideshare.net/CyLab/poncan2

リワード広告とは：

ユーザーに広告を提供し、その成果に対して

一定の報酬（ポイント等）を支払うサービス

システム(poncan)

Rails2.3.8 + passenger

Ruby1.8.7

MySQL5

Memcached(acts_as_cached)

Resque/Redis

運用

止めれない(サーバー停止のメンテは基本なし）

Migrationは使用しない（できない）

→openark kit/oak-online-alter-table

(1日のリリース：２．１回)

(1日コミット数：２２．３回)

(毎日リリース・毎週機能追加・拡張)

背景

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

poncan

事故バグ

漏れ

テストコード(のメンテ)不足

安心感

Specを書けよデコ助野郎！

RSpec

開発メンバー

①導入前の状態

有効なRSpecほぼ無し

自動生成されたtestunitが少々

誰も動かしていない

当然メンテもしていない

②導入直後にやった事

メンテされていないテストコードは削除

-流用できないコード多数

　-そもそも仕様が既に変わっている

自動生成されたコードも削除

テスト用データ

　-fixturesからFactoryGirlに移行

②失敗・教訓（導入直後）

とりあえず動くだけでは不十分

-実行時間が長いと流さなくなる

自動で動かさないと忘れる

　-autotest使うようにした

テストデータを全てFactoryGirlで賄うのは面倒

　-マスタデータはfixtures

-トランザクションデータはFactoryGirl

③しばらく経って（１週間位）やった事

Specを書く対象を絞った

　-まずはmodelから書いていく事にした

　-controllerは後回し

③失敗・教訓（しばらく経って）

ビジネスロジック部分をspecの対象にすべきだった

　-modelだけでは不十分で、(Fat)controllerのロジック部分も対象にしないと無意味

万遍なくspecを書こうとして途方に暮れた

　-全部書く時間ない・モチベーション下がる

　-修正の入った箇所から充実させていった

④慣れてきた頃（１ヶ月位）にやった事

CIを導入した

-手軽なBigTunaを採用

遅い処理の改善

　-テストダブル（モック・スタブ）に置き換え

　-migrationからschema.rb読み込みに変更

④失敗・教訓（慣れてきた頃）

CIの失敗通知が続いてREDに慣れてしまった

　-失敗だけでなく失敗数も通知するようにした

　-オールグリーンを目標に設定

　-だんだんREDが減っていくのを見てモチベ△

メンバー間のspecの書き方に統一性が無くなってきた

　-勉強会・共有会で書き方をある程度共有

　-THE RSPEC BOOK

⑤充実してきた頃（３ヶ月位）にやった事

カバレッジを指標にした

　-rake spec:rcov

テストデータの整理

　-モデル（テーブル）数８０くらい

⑤失敗・教訓（充実してきた頃）

カバレッジは万能じゃない

　-「レガシーコード=テストの無いコード」なので意味はあるが・・・

　-Reekを取るようにした（お手軽/ReekViewer）　https://github.com/Shinya131/reek\viewer

FactoryGirlがパンクした

　-factory.rbに全てぶっ込むのではなく、factoriesフォルダ以下にファイル分割配置

　-リレーション指定やりすぎると破綻（メンテ不能）に

⑥グリーンになって（５ヶ月位）にやった事

trunkとbranchに対してそれぞれCIを回した

　-管理・配信・配信(mixi特化)アプリごとに、それぞれ計６つの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/