既存プロダクトに

RSpec を

導入していく

2019/12/14 平成 Ruby 会議 01
@rry

#heiseirubykaigi

rry と申します
- 平成.rb Organizer
- Vue.js 日本ユーザーグループ
- Vue Vixens
フロントエンドも好きな Rails エンジニアです 🐣

〜宣伝〜

Vue.js は良いものだ

Vue Vixens という
女性向けイベントやっています
- Rails Girls みたいな感じ 😘
12/19（木）Vue Vixens #2 🎄🎅

https://vuevixens-jp.connpass.com/event/156281/

create-nuxt-app で利用できる UI フレームワークを比較する - Qiita

Nuxt.js アドベントカレンダー

9月〜

とあるプロダクトの

保守運用を任された

※ この物語はお仕事でのお話です

モノリシックな Rails

↓

API がいくつかある

↓

今年フロントエンドを Nuxt.js にリニューアル

↓

管理機能の画面はいまだモノリシックな Rails

※ この物語はお仕事でのお話です

RSpec のカバレッジ

5%

引き継ぎ当時...

RSpec をほぼ実装したことがない

よちよちメンバー 4人で保守運用

コードの中を確認...

RuboCop ... 入っていない
- 警告が出すぎて入れられない
バックオフィス向け管理機能
- 仕様を誰も把握していない

長すぎるメソッド...
改修しづらいコード...
使われていない機能...

🍝

逃げちゃダメだ！

既存プロダクトに

RSpec を

導入していく戦い

タイトル・改

これからどうする？

我々がとったアクション

コーチを召喚

ねらいは、メンバーの
スキルアップとテストの充足、
技術負債 🍝 の解消

どことは言いませんが、界隈で有名な
ESM さんにお願いしました。

我々がとったアクション

計画づくり

「テストがないとデグレーションしてしまう！」

「今は機能追加よりもテストやリファクタリングを優先させる」

CEO や他部署に合意してもらい、
技術負債解消ターンに入った

我々がとったアクション

実行

←今ココ

第 1 期：Unit test 系の Spec を充足させる

第 2 期： Integration test 系の Spec を充足させる

↑今ココ

第 3 期：リファクタリング 💪

テストの考え方について

基本的な自動テストの考え方や RSpec の書き方は
これらを読めば分かる

Read Everyday Rails - RSpecによるRailsテスト入門

O'Reilly Japan - 初めての自動テスト

テストの考え方について

また、「使えるRSpec入門」シリーズ

なども大変お世話になっている。

使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita

使えるRSpec入門・その2「使用頻度の高いマッチャを使いこなす」 - Qiita

使えるRSpec入門・その3「ゼロからわかるモック（mock）を使ったテストの書き方」 - Qiita

使えるRSpec入門・その4「どんなブラウザ操作も自由自在！逆引きCapybara大辞典」 - Qiita

今日から使える！RSpec 3で追加された8つの新機能 - Qiita

これらを読んで基本が分かった
ところで、次は実践編 🚀

1. テストピラミッド、
上から降るか下から登るか

の詳しい説明は、

「初めての自動テスト」でも

紹介されています。

Unit テストは速く実行できる
- シンプルな Unit テストでパターンを網羅
  - model, decorator, uploader などの Spec
Servise（結合）テストは Request Spec でまとめる
- Controller Spec などは省略して書かない
UI（E2E）テストは System Spec で書いていく
- 実行速度が遅いため、網羅的に書くには不向き

テストピラミッド

1. テストピラミッド、
上から降るか下から登るか

我々は model や decorator などの

Unit テストから書いていくことを
「計画づくり」のときに決めた。

メンバーが RSpec に慣れている場合
- バグが起こったときに検知しやすいよう、
  E2E などの外側のテストから書いていく
メンバーが RSpec に慣れていない場合
- 難易度が低くテストに慣れることができる
  Model などの Unit テストから書いていく

2. テストを実装する前に、

describe、context などを使って、

まずはペンディングテストを書いていく

「何をテストしたいのか」をペンディングで書いていく

ことにより、頭が整理されるため

describe Article, type: :model do
  # テスト対象（メソッド名など）
  describe '#published' do
    # 状態（〜の場合）
    context '非公開記事がある場合' do
      # 期待する出力（〜のこと）
      it '公開記事のみ取得できること'
    end
  end
end

describe Article, type: :model do
  describe '#published' do
    context '非公開記事がある場合' do
      before do
        create(:article, name: '公開記事', published: true)
        create(:article, name: '非公開記事', published: false)
      end

        subject(:article_published) { Article.published }

        # 期待する出力（〜のこと）
        it '公開記事のみ取得できること' do
          expect(article_published).map(&:published)).to match_array([true])
        end
    end
  end
end

「設計をテストで表現できる」のが RSpec の良さ
「ふるまい」を先にペンディングで書いていく（BDD）
- 機能実装するときも同じようにペンディングテスト
  から書いていくと🙆

3. あくまで「ふるまい」をテストすること

マジックナンバーや、中身が分かりにくい
（または変動する恐れのある）値で検証するのは ❌ 👮

describe Article, type: :model do
  describe '#some_data' do
  	context '何らかのデータがある場合' do
      let(:bad_article) { create(:article, title: Foo.title, description: Foo.description, tag_type: 1) }
      let(:good_article) { create(:article, title: 'タイトル', description: 'ディスクリプション', tag_type: 'Ruby') }

      subject(:bad_some_data) { bad_article.some_data }
      subject(:good_some_data) { good_article.some_data }

      it 'データの配列が返ってくること' do
        # 分かりにくい例 ×
        expect(bad_some_data).to eq [article.title, article.description, 1]

        # 分かりやすい例 ○
        expect(good_some_data).to eq %w(タイトル ディスクリプション Ruby)
      end
    end
  end
end

我々は全知全能だからコードの中身を知っているだけ。

メソッドの中身がどうなっていようと、期待する値を受け取れればそれで良い。

4. 「テストが書けない！」

ひとつのメソッドに仕事をさせすぎている場合
中のロジックについて、テストを書くのが
あまりにも大変になる...

その場合は、最低限テストで担保したい部分
（書ける範囲）を書き、その後にリファクタリングする
- テストなしでリファクタするのは ❌
無理のある範囲をわざわざテストしなくても良い
- もし手動の動作確認で事足りるなら、最低限テストを書いてリファクタリングした後に、きちんとしたテストを書けば 👌

5. private メソッドのテスト？

リファクタリングする前のコードにテストを書こうと
したら、プライベートメソッドのテストを書くはめに

書けなくもない... けど... 😑
どうしても private メソッドをテストしたいときは、
設計がおかしいかもしれない
- send でテストを書いた後で良いので、リファクタリングしていこう
- クラスに切り出すと幸せになれるかもしれない

let(:creator) { Admin::DataCreator.new() }

subject(:contract) {
  # send を使って private メソッドを呼び出して検証することはできる...
  creator.send(:foo, 1, 2, 3)
}

現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ

privateメソッドのテストについての考え方 #yochiyochirb - No Purpose

参考になった（気持ちがよく分かった）記事
- リファクタリングする前提で、private メソッドの
  テストを書くのは致し方なしだと思う
  - いくつか（ガッツリ）private メソッドのテストがマージされている
  - もちろんリファクタ対象になっている

RSpec の

便利な書きかた Tips

1. これが便利 factorybot

create で関連するモデルも作れる
最低限のバリデーションが通る factory を作ると、
応用が利いて便利

# Table name: users
# ...
# id                     :bigint           not null, primary key
# name             :string(255)
# coach_id          :bigint
# ...

describe User, type: :model do
  describe '.coachs' do
    before do
      create(:user, name: 'テスト A さん', coach_id: nil)
      # 関連するモデルを作れる
      create(:user, name: 'テスト B さん', coach: create(:coach))
    end

    subject(:user_coachs) { User.coachs }

    context 'coach を持っているデータが存在する場合' do
      it 'coach を持っている user が取得できること' do
        expect(user_coachs.count).to eq 1
        expect(user_coachs.first.name).to eq 'テスト B さん'
      end
    end
  end
end

2. receive_message_chain に引数を
複数指定したい

describe 'Api::ContactsController', type: :request do
  describe '.received_mail' do
    subject(:request) {
      post '/api/contacts', params: { contact: { name: '太郎', email: 'taro@co.jp', message: 'メッセージです' } }
    }

    # ...
    # リクエストが成功することなどのテスト
    # ...
    # Api::Mailer.received_mail(Contact.new).deliver
    
    before do
      allow(Api::Mailer).to receive_message_chain(:received_mail, :deliver)
        .with(instance_of(Contact)).with(no_args)
    end

    it 'mailer が呼び出されていること' do
      request
        
        expect(Api::Mailer).to have_received(:received_mail).once
      end
    end

with を複数つなげることができる
anything や no_args など引数マッチャを指定すると
より明示的にすることができる

3. 標準出力のテスト

describe Foo, type: :service do
  describe Foo::Generator do
    describe '.call' do
      subject(:foo) { Foo::Generator.new }

      it 'メッセージが標準出力されること' do
        expect { foo.call }.to output("ファイルを出力しました。\n").to_stdout
        # .to_stderr で標準エラー出力も検証できる
        # expect { foo.call }.to output("エラーが発生しました。\n").to_stderr
        expect(File.exist?(file)).to be true
        end
    end
  end
emd

RSpec にある output().to_stdout が便利
- output マッチャ以外にも便利なマッチャが沢山ある

`output` matcher - Built in matchers - RSpec Expectations - RSpec - Relish

テストを書くときは RSpec の公式ドキュメント
Relish を読む

まとめ

RSpec の良いところ
- Spec がUnit テスト系から Integration テスト系まで手厚く用意されており、過不足なくテストが書けること
DSL で読みやすい
- 読みやすいということは、ドキュメントとして仕様を把握しやすい
モックが簡単に書けたり、気の利いたマッチャが多く、
テストが書きやすい
- 書きやすいということは、機能の修正やリファクタリングがしやすい

つまり...？

変化に強くなれる💪

Rails や Gem のバージョンアップ・導入
仕様変更や機能追加がしやすくなる
テストがあることによりこれらに
安心感が持てる

今のプロダクトがリファクタリング期に
入るのは、あともう少しだけかかりそう
ですが...

少しずつ開発に

安心感が持てるようになってきた 🎉

System Spec とあと少しのテストを除いてテストが充足してきた
- 機能改修にも着手しつつある
コーチに
圧倒的感謝 🙏

RSpec導入奮戦記/The struggle of introducing RSpec - Speaker Deck

ちなみに...

RSpec のカバレッジ

5%→15%

俺たちの戦いは...
まだ始まったばかりだ...！

ところで...

突然ですが...

rry、1月から
STORES.jp に転職します。

12月いっぱいまで
- フロントエンド（Nuxt.js）側の引き継ぎ
メンバーひとりひとりが RSpec の実装に慣れてきた
- チームの雰囲気と開発速度が安定してきた
新しいことにチャレンジしたいと思った 💪

ご静聴

ありがとうございました！

詳しい話や質問は懇親会
でお声がけください 🙋

引き続き平成 Ruby 会議を楽しみましょう！

逃げちゃダメだ！既存プロダクトに RSpec を導入していく戦い

By rry

逃げちゃダメだ！既存プロダクトに RSpec を導入していく戦い

平成 Ruby 会議 01 での発表資料です。

3,466

rry

other: https://speakerdeck.com/ryamakuchi

chiba_rry

既存プロダクトに

RSpec を

導入していく

〜 宣伝 〜

Vue.js は良いものだ

9月〜

とあるプロダクトの

保守運用を任された

RSpec のカバレッジ

5%

RSpec をほぼ実装したことがない

よちよちメンバー 4人で保守運用

コードの中を確認...

RuboCop ... 入っていない

警告が出すぎて入れられない

バックオフィス向け管理機能

仕様を誰も把握していない

長すぎるメソッド...

改修しづらいコード...

使われていない機能...

逃げちゃダメだ！

既存プロダクトに

RSpec を

導入していく戦い

我々がとったアクション

コーチを召喚

我々がとったアクション

計画づくり

我々がとったアクション

実行

テストの考え方について

テストの考え方について

テストの考え方について

これらを読んで基本が分かった ところで、次は実践編 🚀

1. テストピラミッド、 上から降るか下から登るか

1. テストピラミッド、 上から降るか下から登るか

2. テストを実装する前に、

describe、context などを使って、

まずはペンディングテストを書いていく

3. あくまで「ふるまい」をテストすること

4. 「テストが書けない！」

5. private メソッドのテスト？

RSpec の

便利な書きかた Tips

1. これが便利 factorybot

2. receive_message_chain に引数を 複数指定したい

3. 標準出力のテスト

まとめ

まとめ

つまり...？

変化に強くなれる💪

今のプロダクトがリファクタリング期に 入るのは、あともう少しだけかかりそう ですが...

少しずつ開発に

安心感が持てるようになってきた 🎉

System Spec とあと少しのテストを除いてテストが充足してきた

機能改修にも着手しつつある

コーチに 圧倒的感謝 🙏

RSpec のカバレッジ

5%→15%

俺たちの戦いは... まだ始まったばかりだ...！

ところで...

突然ですが...

rry、1月から STORES.jp に転職します。

ご静聴

ありがとうございました！

詳しい話や質問は懇親会 でお声がけください 🙋

引き続き平成 Ruby 会議を楽しみましょう！

逃げちゃダメだ！既存プロダクトに RSpec を導入していく戦い

More from rry

〜宣伝〜

これらを読んで基本が分かった
ところで、次は実践編 🚀

1. テストピラミッド、
上から降るか下から登るか

1. テストピラミッド、
上から降るか下から登るか

2. receive_message_chain に引数を
複数指定したい

今のプロダクトがリファクタリング期に
入るのは、あともう少しだけかかりそう
ですが...

コーチに
圧倒的感謝 🙏

俺たちの戦いは...
まだ始まったばかりだ...！

rry、1月から
STORES.jp に転職します。

詳しい話や質問は懇親会
でお声がけください 🙋