Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
RSpec導入奮戦記/The struggle of introducing RSpec
Search
muryoimpl
November 03, 2019
Technology
2
1.9k
RSpec導入奮戦記/The struggle of introducing RSpec
2019/11/03 (日) に開催された 富山 Ruby 会議 01 の LT で使用した資料。
muryoimpl
November 03, 2019
Tweet
Share
More Decks by muryoimpl
See All by muryoimpl
人魚とたわむれる
muryoimpl
0
20
Kanzawa.rbのLT大会を支える技術の裏側を変更する Ruby on Rails + Litestream 編
muryoimpl
0
1.3k
Kanazawa.rb LT大会用/kzlt コマンドの説明 2024/01版
muryoimpl
0
2.9k
kzltコマンドの新たなソリューションについて
muryoimpl
0
2.9k
俺とTODOアプリ~Linearの変~
muryoimpl
0
2.5k
POSIX文字クラスでの躓き
muryoimpl
0
2.3k
/kzlt コマンドとは
muryoimpl
0
950
meetup.kzrb.org の更新を考える 事前激闘編
muryoimpl
0
1.5k
meetup.kzrb.org の更新を 考える ゆるふわ編
muryoimpl
0
1.5k
Other Decks in Technology
See All in Technology
AWSにおけるTrend Vision Oneの効果について
shimak
0
130
AIAgentの限界を超え、 現場を動かすWorkflowAgentの設計と実践
miyatakoji
0
140
PLaMo2シリーズのvLLM実装 / PFN LLM セミナー
pfn
PRO
2
990
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
9k
20201008_ファインディ_品質意識を育てる役目は人かAIか___2_.pdf
findy_eventslides
1
450
業務自動化プラットフォーム Google Agentspace に入門してみる #devio2025
maroon1st
0
190
AIが書いたコードをAIが検証する!自律的なモバイルアプリ開発の実現
henteko
1
350
Goに育てられ開発者向けセキュリティ事業を立ち上げた僕が今向き合う、AI × セキュリティの最前線 / Go Conference 2025
flatt_security
0
350
空間を設計する力を考える / 20251004 Naoki Takahashi
shift_evolve
PRO
3
360
英語は話せません!それでも海外チームと信頼関係を作るため、対話を重ねた2ヶ月間のまなび
niioka_97
0
120
Findy Team+のSOC2取得までの道のり
rvirus0817
0
350
SwiftUIのGeometryReaderとScrollViewを基礎から応用まで学び直す:設計と活用事例
fumiyasac0921
0
140
Featured
See All Featured
Optimizing for Happiness
mojombo
379
70k
Statistics for Hackers
jakevdp
799
220k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Large-scale JavaScript Application Architecture
addyosmani
514
110k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.1k
Code Reviewing Like a Champion
maltzj
525
40k
Speed Design
sergeychernyshev
32
1.1k
Faster Mobile Websites
deanohume
310
31k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
890
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
GitHub's CSS Performance
jonrohan
1032
460k
Balancing Empowerment & Direction
lara
4
680
Transcript
RSpec 導入奮戦記 2019/11/03 富山 Ruby 会議 01 #toyamark muryoimpl
とあるプロジェクトのお話 既存のRailsアプリケーションに対し、前任者が用意したRSpec coverage 5% の状態から、RSpec をほぼ実装したことのないメン バー4人とともに、学習しつつ、model, decorator, uploader, service
のテスト, request spec, system spec を作成してリファク タリングするところまでやるぞ!という、Railsアプリの運用を楽しく しよう!とチャレンジをしている最中の物語。
ねらい • テストを作成する文化を根付かせたい • 本体コードが になっているので、リファクタリングして意図 のわかるコードにしたい • 上記2つを通して、メンバーのスキルアップを図りたい
編成 • メンバー 4 人 ◦ RSpec ほぼ実戦では書いたことがない ◦ 伸びしろ
100% • 私 ◦ コーチ ◦ テストコードのレビュー ◦ 難易度高いところをひたすらテスト書く係
現時点での計画 • 機能のエンハンスは期間限定で停止 。 ただ し、調査・修正は実施する。 ◦ なるべくテスト作成に力を注ぐため • 本体をリファクタリングしたい欲をぐっと堪え てテスト作成に専念する
。 ◦ 実行単位の難易度を下げる ◦ いろんなところに波及しがちなのでテスト揃え てからやる • 難易度を考え、model のテストから順に作成 していくこととする。 ◦ テストのフィードバックが一番速いはず ◦ 容易なメソッドが多かったため ① ② ③ 当作戦は3期計画を予定している。 ① model/decorator/uploader テスト作成期 ② request spec, system spec作成期 ③ リファクタリング期 ※現在 ① 期後半戦 (作戦開始後ほぼ1ヶ月)
実践編 その1 • 当作成実行前に、モブプロ形式でテーブルに対応した ActiveRecord のモデルを 使ってブートキャンプを行う ◦ データ作成で FactoryBot
を使う、それを it/specify 内で使うために let を使う ◦ User#full_name で “#{last_name}#{first_name}” に対して eq matcher を使う ◦ .find で ActiveRecord::RecordNotFound が発生することを expect { … }.to で確認する ◦ .find_by で be_nil を使う, allow を使って .find_by! 相当の挙動を and_raise で実現する ◦ #save で change matcher, valid? 呼び出しに対し have_received matcher を使う ◦ allow/expect は設定するobjectが検証対象のobjectと同一かどうか注意する • 実戦前に rubocop-rspec を導入しておく ◦ 既存のテストについては警告が大量に出るので除外し、テスト追加時に併せて対応する ◦ コーチが指摘する量を減らし、その時間をより本質的な指摘に使うため ◦ 警告食らってドキュメント見て Copの意図を理解してもらう狙いも
実践編 その2 • モブプロ形式でモデルのテストを追加していき、その場でマージしていく ◦ 2時間/日 を確保してもらって、ドライバを替えながら 対象 VS 私たち
でテストに立ち向かう ◦ 別件調査等でテスト作成の作業時間が確保できないメンバーもテスト作成、レビューができるように 会として設定している => 特にレビューが滞りがち ◦ PR レビュー形式だとコーチがピンポイントで better な案を指摘しがち => テスト作成者たちが考え、議論することを重視 し、指摘はクイズ形式、解答は意図を添えて ◦ モブプロ以外にも時間が確保できるメンバーは PR作成、質問をバンバンしてもらう ◦ 出ているPRもこの時間でみんなでレビューして指摘、マージする ◦ 実は他のコードをコピペしてきて解決しようとするのを抑止している • コーチはひたすら事例を作成するようにテストを量産してレビューにまわす ◦ 書き方のパターンを提供する ◦ 新たなパターンが出てきた場合は、モブプロ時に紹介する ◦ …ちょっと機会を奪っている気もする …
伝承編 これらのリンクを紹介し、一部説明を加えた • RSpec によるユニットテストの書き方 - recompile.net ◦ https://recompile.net/posts/how-to-write-unit-test-with-rspec.html •
RSpecのletを使うのはどんなときか?(翻訳) ◦ https://qiita.com/jnchito/items/cdd9eef2ed193267c651 • GETTING_STARTED.md - thoughtbot/factory_bot ◦ https://github.com/thoughtbot/factory_bot/blob/master/GETTING_STARTED.md • スペックのス ◦ https://magazine.rubyist.net/articles/0021/0021-Rspec.html ◦ https://magazine.rubyist.net/articles/0023/0023-Rspec.html • 改めて学ぶ RSpec ◦ https://magazine.rubyist.net/articles/0035/0035-RSpecInPractice.html • Everyday Rails - RSpec による Rails テスト入門 ◦ https://leanpub.com/everydayrailsrspec-jp
よく出た注意点 • 振る舞いをテストすること。振る舞いのテスト != メソッドのテスト ◦ carrierwave の store_dir のパス比較しても嬉しくない。動作させた上で
store_dir に保存されること を確認したい • use_transactional_fixtures, DatabaseCleaner, DatabaseRewinder 等の設定か ら example ごとにデータが削除 or ロールバックされているか確認する ◦ この設定が入っているにもかかわらず、着手当初は手前の exampleで作成したデータが残っている こと前提でテストを書きがち。テストの独立性の話で --order rand と一緒にお伝えしておくのがよさ そう。 • テスト作成をガイドするのもテスト ◦ テストをどう書くかを悩むときにテスト流さずに机上で悩みがち。簡単に手元でテストが流せるから、 バンバン流してフィードバックもらって作っていって欲しい (願)。
はたして現状はどうなっているか (1ヶ月経過時点) • メンバーはRSpec読み書きできるレベルには到達した ◦ rspec-mock である処理を握りつぶしたり …を書くのはもう少し先の話 ◦ 本体コード修正PRにもテストが付属してくるようになった
◦ PRレビュー時に他のメンバーからもテストについて指摘が出てくるようにもなった ◦ subject, let をうまく使った読みやすいテストコードが出てくるようになった • 思ったよりテスト作成の速度が出ていない ◦ 問い合わせによる調査、修正の時間が思っていたよりある。時間の確保が課題になった ◦ 時間確保のため、モブプロ時間の内容の見直しや、作業の仕方を模索中。スプリントごとに施策を 替え、試してよさそうなものを採用するようにしている • レビューに思ったより時間がかかる ◦ テストの追加がクラス単位なので、クラスのメソッドが多いと PR が大きくなり、レビュアーの負担に なってきている => 適当な単位で区切ってはいるものの匙加減難しい
実感として • 最初はモブプロ形式でみんなで進めて、レビューされ慣れたあたりで各自担当を もってテスト追加していく、くらいがよさそう • メンバーのモチベーションが高いことに助けられている。 ただでさえ負債の回収フェーズでマイナスに気持ちになりがちなので、過度なプレッ シャーは取り除く • まだまだ始まったばかりなので、コツコツ進めてリファクタリングに到達するぞ!
私からのお願い 頼む!アプリケーション書くときに テストコードも書いてくれ!!! 頼む!