# 【第7日最終日】EverydayRails輪読会合宿(2022GW) (2022\-05\-05\)

###### tags: `Everyday Rails`

[EverydayRails輪読会合宿\(2022GW\) ノートまとめ \- HackMD](https://hackmd.io/cXyZTiHOTC-LYhcOYDw3gA)

## 目次

[TOC]

### 司会
- @eatplaynap
[タイマー](https://timer.onl.jp/)
### ドライバー
- @Saki

### スタート地点
P185バックグラウンドワーカーのテストの途中 から
eatplaynap トミー, fuwa, yocajii, uda, Saki, paru
### [タイムテーブル(案)]
07:00-07:10 歓談
07:10-08:10 1タームめ輪読(ラスト10分感想記入+発表)
08:10-08:20 10分休憩
08:20-09:20 2タームめ輪読(ラスト10分感想記入+発表)
09:20-09:50 30分休憩
09:50-10:50 3タームめ輪読(ラスト10分感想記入+発表)
10:50-11:00 10分休憩
11:00-12:00 4タームめ輪読(ラスト10分感想記入+発表)
12:00解散

### ◆ P185バックグラウンドワーカーのテストの途中 から P189メール送信をテストするの下の鍵のところ まで(8:00)
#### 共有スペース

#### 確認したい/わからなかったこと ↓自由に記入してください！

- mailerのテストファイルをコマンドで作るときに自動生成されたpreview用のテストはどう使うのか謎
- perform_laterとperform_nowの違い
- [ActiveJobのperform_laterとperform_nowの違い - Qiita](https://qiita.com/jnchito/items/3482a30262874b80a8e4)
- 後で読む

#### それぞれの気づき

- @uda
- `perform_later`はキューが空いたら実行され、`perform_now`は即時実行される
- デバッグ時にまだ呼ばれてないletを呼ぶと生成されてしまうので注意。countを使って存在確認するのがよさそう
- ジョブがメソッドを呼んでいるかのテストの書き方はなんとなくわかったけど、geocoder gemの中身を理解してないのでぼんやりしている
- メール送信のテストは比較的わかりやすかった

- @yocajii
- `let`は呼んだ瞬間に生成される
- デバッグ中に呼んでも同じ（忘れがち）

- @fuwa
- `let` は読まれた瞬間に生成される
- `ActiveJob`マッチャを使うには`ActiveJob::Base.queue_adapter = :test` を設定する必要がある

- @paru871
- instance_doubleでテスト用のモックユーザーを作る→モックユーザーに対してgeocodeメソッドがどこかで呼ばれるよということをRSpecに伝えておく(RSpecの気持ちになる)→バックグランドジョブを呼び出す(perform_now)
- letは呼ぶとその時点でインスタンスを生成する(メソッドになる)
- メールのtoとfromは配列であることと件名は決め打ちなので、等値性をチェックする意味でeqマッチャを使用していた、match、containマッチャとの違いを感じ取りたい

- @Saki
- `perform_now`はすぐにテスト実行する
- あらかじめ「こういうことをテストしてほしい」と伝えておかないとエラーになってしまう

    # spec/jobs/geocode_user_job_spec.rb
    RSpec.describe GeocodeUserJob, type: :job do
      # userのgeocodeを呼ぶこと
      it "calls geocode on the user" do
        user = instance_double("User")
        expect(user).to receive(:geocode) #先に予約して書く!
        GeocodeUserJob.perform_now(user) #これを先に書くとエラーになる
      end
    end

- `perform_later`と`perform_now`はそもそもアプリの仕組みが難しかったので、必要なときに戻ってこようかな
- [ActiveJobのperform\_laterとperform\_nowの違い \- Qiita](https://qiita.com/jnchito/items/3482a30262874b80a8e4)
- メール送信のテスト
- `let(:mail) {UserMailer.welcome_email(user)}`は、`app/mailers/user_mailer.rb`の`welcome_email(user)`メソッドを呼んでる。これがサーバー側がもつ情報(addressや件名や送り先のメアド)を設定してるっぽい
- `let`はbinding.breakで呼ばれている確認のため`user`とかいた時も呼んでしまうので、注意!(デバッグでも呼べてしまう)→やり直して、`User.count`すると0と返ってきて、まだ呼ばれてないことが分かった。

- @eatplaynap
- `let`は呼んだ時点で評価されるので、デバッガーで止めた中でインスタンスが生成されているのか確認用に呼んだらその時点で作成されてしまって確認にならない…
- 生成タイミングを確認するには`モデル名.count`などで数を確認するのが無難そう

### ◆ P189メール送信をテストするの一番下の行 から P196Webサービスをテストするのvcr.rbのコード まで(9:10)
#### 共有スペース

#### 確認したい/わからなかったこと ↓自由に記入してください！

#### それぞれの気づき

- @Saki
- `spec/system/sign_ups_spec.rb`の`perform_enqueued_jobs`の中に、ユーザー登録の処理を入れておかないと、mail.toの中身がnilになってしまい`aggregate_failures do~`のテストが失敗する
- メールのテスト：アプリの仕様がそもそもユーザーが追加されたら、`after_create`コールバックが動くようになっている。`models/user.rb`を見るとわかる。

class User < ApplicationRecord
    
 after_create :send_welcome_email
    
 def send_welcome_email
   UserMailer.welcome_email(self).deliver_later
 end
end  

- `allow`はスタブorモック化していて、これにspy機能がついてるイメージ
- p.194のコードの`user = FactoryBot.create(:user, last_sign_in_ip: "161.185.207.20")`の`last_sign_in_ip`は、以下で定義されてるから使えるみたい

  geocoded_by :last_sign_in_ip do |user, result|
    if !user.local? && geocode = result.first
      user.location = "#{geocode.city}, #{geocode.state}, #{geocode.country}"
      user.save
    end
  end

- @eatplaynap
- ユーザー登録後自動的に送られるWelcome Mailをテストしたい場合はsystem specにもUserのmodel specに書いてもよい
- system specの方は何をやってるか分かりやすいけどいちいちテスト内でユーザーの新規登録を行う必要があるのは冗長な感じもする
- IPアドレスは連番じゃない

- @fuwa
- スパイがいまいち理解できていない気がする。。（なんとなく意味はわかるけど自分で書けと言われたらできなさそう）
- 最後の方眠くて死んでました
- 👼
- 📣

- @cafedomancer
- メールがコールバックで送信されるようになっていれば、system spec のような実行コストの高いテストではなく model spec のような実行コストの低いテストで検証できるんですね
- `perform_enqueued_jobs` すると非同期処理を実行してくれて、かつその完了を待ち合わせてくれる？
- `expect` を先に書いたり後に書いたりしていて難しい...

        # 先に書く
        expect(project).to 
          receive_message_chain(:notes, :search).with("rotate tires")

        # 後に書く
        allow(UserMailer).to
          receive_message_chain(:welcome_email, :deliver_later)
        expect(UserMailer).to
          have_received(:welcome_email).with(user)

        # 先に書くケースを後に書くケースに直せるのでは？
        allow(project).to
          receive_message_chain(:notes, :search).with("rotate tires")
        expect(project).to
          have_received(...) # ここはなんて書いたらいいんだろう

- @uda
- Userのモデルスペックに書いたメール配信のテストは短くまとまっているけどシステムスペックに比べて難易度は高い
- メールはバックグラウンドプロセスで送信されるので`perform_enqueued_jobs`ブロックで囲む必要がある。時間の問題じゃなくてこれがないと実行されない
- `perform_enqueued_jobs`はActiveJob::TestHelperモジュールが提供
- VCRは聞いたことがあるけど使ったことないので楽しみ

- @yocajii
- `allow(...).to receive_message_chain(...)`でスパイという仕組みが使えるらしい
- `receive_message_chain`はレガシーなコードをテストするためのメソッドらしい
- ユーザーが作成されたらメールが送信されることをテストするタイミングを分かっていないとうまくテストできなさそう

- @paru871
- スパイ・・・テストダブルに似ているが、テストしたいコードが実行されたあとに発生した何かを確認できる→P192の例ではクラス（UserMailer）に対して、期待されたオブジェクト（user）とともに、目的のメッセージ（:welcome_email）が呼び出されたかどうかを、have_receivedマッチャを使って検証している
- スパイを使う必要性・・・P192の例の場合は、Mailerを実行せずにユーザーを作成して変数に入れておきたいから

## 30分休憩！(9:26〜9:56)
P196Webサービスをテストするのvcr.rbのコード から再開します〜

### ◆ P196Webサービスをテストするのvcr.rbのコード から P203フィーチャを定義するの終わり まで(10:40)
#### 共有スペース

#### 確認したい/わからなかったこと ↓自由に記入してください！

#### それぞれの気づき

- @Saki
- gem`vcr`で、`vcr.rb`に設定の記述→テストで`vcr: true`と書くことで、テスト実行1回目のリクエスト/レスポンスの記録が`spec/cassettes`ディレクトリに保存される。テスト実行２回目以降は、このファイルの内容を使ってリクエスト/レスポンスをスタブ化している
- vcr
- vcr で機密情報をマスキングする場合(投稿者が伊藤さんの同僚)
- [VCR で外部 API へのリクエストをダンプするときに機密情報をマスクしたい \- Qiita](https://qiita.com/gotchane/items/c2c29c0063bd44246510)
- 試しにファイルの`body`の内容を変更してみたら、テストが落ちた
- `time bundle exec rspec spec/models/user_spec.rb:40`と先頭に`time`をつけることで、実行にかかった時間を知れる
- 1回目と2回目図ってみたが、早くなってるけどそんなに差はなかった...
- 梅本さん、森塚さんいわく、カセットファイルをバージョン管理システムにあげている。bootcampもあげている。機密情報が入ったものをコミットに含めないよう気をつけよる。
- 演習問題：deviseのパスワードリセット機能のテスト

- @eatplaynap
- > Rails の開発者の多くはプロジェクトのバージョン管理システムからカセットファイルを除外することを選択します。
- 梅本さん森塚さん曰くそうでもないらしい(bootcampでも含めている)
- とりあえずGitHubにあげる前にサニタイズの設定をして機密情報をあげないように注意
- [VCR で外部 API へのリクエストをダンプするときに機密情報をマスクしたい \- Qiita](https://qiita.com/gotchane/items/c2c29c0063bd44246510)
- 演習問題でできそうなこと
- とりあえずDevise のパスワードリセット機能のテストはできそう
- focusのことはこのブランチの設定ファイルに書いてないみたいだから`bundle exec rspec`を実行したら全テストが走ってしまった…

- @uda
- VCRを使うとカセットを再作成するタイミングとかGit管理するかとか、考えないといけないことがいろいろありそう
- VCRの設定ファイル`support/vcr.rb`の内容は難しいけど説明があったからなんとなくわかった
- TDDどこまで読めるだろ...
- UNIXコマンドの先頭にtimeをつけると実行時間がわかる
- rspec に限らない

- @cafedomancer
- VCR 便利そうだけど、API アクセスが副作用を伴うケースで問題は起きないのかな？
- なんらかのデータが作成・変更されるようなケース (登録、支払い、etc.)
- system spec で TDD するの難しそう...
- system spec の字面から画面を想像しながら書かないといけないような？
- 肝心の webmock の説明が端折られていた (泣)

- @yocajii
- VCR便利すぎてすごい
- ここまでRSpecの使い方を見てきたからか、テスト駆動開発もできそうな気がしてきた
- やっぱり難しいらしい

- @fuwa
- VCR便利そう。外部APIを使うときは使った方が良さそう。
- TDDあんまりやったことがないので勉強する良い機会かなぁと思う

- @paru871
- 自作サービスで外部APIを使う人が多いと思うのでVCRが役に立ちそう
- コマンドの前に`time`をつけると実行時間を計測できる
- テスト駆動開発はシナリオ作りから。必要な情報をコメントとして書いてからテストコードと置き換えていくと簡単。
- focusタグのみ実行するかどうかを設定してるのは`spec/spec_helper.rb`(書籍だとP175)

### ◆ P204レッドからグリーンへ から P214レッドからグリーンへの終わり まで(11:50)
#### 共有スペース

#### 確認したい/わからなかったこと ↓自由に記入してください！

#### それぞれの気づき

-

- @eatplaynap
- 合宿でTDDの最後まで見届けられてよかった〜
- 「プロジェクトの完了」というシンプルな機能でも今の状態だと不完全(プロジェクト一覧からなくなったりしないし、完了→未完了への変更機能もない)なので、ここから先またTDDで進めるのを考えると途方もない感じがした
- みなさま合宿参加ありがとうございました〜😄いろいろあって楽しかったし勉強になったので自分はやってよかったなって思いました！

- @cafedomancer
- だいたい終わった！
- system spec で TDD するのはやっぱ大変そう...。グリーンになるまでの 1 サイクルが長めになっちゃうので「できた！進んでる！」っていう気持ちになかなかなれない...。
- 落ちるテストを先に書くのは重要だと思った。いつも通るテストかもしれないので。
- 今回の合宿は無理のない範囲で行われた？

- @uda
- TDDひととおりできてよかった！
- でもこの例だとまわりくどくて大変そうだと思った。実装をこんなに細かくしていく忍耐性がない...
- ちゃんと復習しなきゃ😫

- @fuwa
- TDDの流れが一通りできてよかった
- 実際TDDした方が良いのかはまた別の議論になりそう
- 今回は比較的シンプルな部分だったと思うけど、複雑なところでTDDしようとすると迷子になりそうな気もする
- 1日おやすみしましたがなんとか最後まで合宿に参加できてよかったです〜！
- えらい！！！

- @yocajii
- テスト駆動開発分かりそうと思ったのは気のせいだった
- レッドからグリーンにしていく手順というか考え方は分かってきたかも
- system spec だと粒度がデカすぎるので、もっと小さいところでやってみたほうが良さそう
- 合宿で読み込むことができて、一人で読んでいる時にどれだけ適当だったかも分かった…
- サンプルコードを打って、何をやっているか理解していくことで、RSpecだけでなくRailsやRubyのことも前より分かるようになった

- @Saki
- 合宿皆勤した!この合宿のおかげでGW充実していました
- えらい！！！
- 最初のシナリオ作りでこけると詰みそう。。最初はテスト駆動でかくと果てしない感じがするが、長い目で見ると良いのかな...梅本さん>普段テスト駆動されていないそう。森塚さん>システムスペックは重い。
- 自作サービスでテスト駆動でシステムスペックから書いていくかは分からないが、どちらにせよしっかりどういう処理を行うアプリを作るか、ペーパープロトタイプでしっかり考えておかないと、と思った
- 梅本さん>自作サービスでテスト駆動で書くのはできないと思う。書くには、設計できていないといけない。設計スキルが十分にないといけないので。
→なるほど!
- 落ちないテストを最初に書くことが大事!`
- [なぜテストを書くの？（または書かないの？） 〜テストコードの7つの役割〜 / \#tamarubykaigi01 \- Speaker Deck](https://speakerdeck.com/jnchito/number-tamarubykaigi01)
- 梅本さん>`categories.position`削除のPRをレビュー依頼に出せました😭✨まだ気は抜けないですが、ありがとうございました
- おつかれさまでした :tea:

- @paru871
- テスト駆動開発で1つずつエラーを解消していくのはコツコツ地道な作業だったが最初のシナリオ作りの方向性を間違えるとあとが大変そうだと思いました。TDD、自分には耐えられるかどうか。。
- この章の残りはあと5ページ、もう少しで終わりだったので早いうちに自分で読み切っておこうと思いました。
- RSepcを一気に合宿で学べて本当によかった。一人では絶対に読めなかったです。ご参加の皆さんご一緒してくださってありがとうございました〜🙏
- 朝7時からに変更になって、人間の行動らしくなってよかったと思いました😁

## P215外から中へ進む（Going outside-in）以降は各自で学習しましょう〜！