テストって楽しい！開発を加速させるテストの魅力 / Testing is Fun! The Fascinating of Testing to Accelerate Development

RUNTEQ内イベント RUNTEQ.rb 登壇資料

Transcript

1. テストって楽しい！ 開発を加速させるテストの魅力 2025/4/26 RUNTEQ.rb 遠藤 薫（END）
2. self.introduction 遠藤 薫（END） RUNTEQ 6期生（2020年1月入学） 2020年9月にエンジニアとして就職する 2023年2月に株式会社ファインディ入社 技術スタックは Rails, React 趣味はリアル脱出ゲーム・ボードゲーム @aiandrox
3. テストといえば？
4. テストといえば？ RSpec t_wadaさん
5. テストに対する実態調査 「テスト」、書いていますか？　
6. テストに対する実態調査 「良いテスト」、書いていますか？　
7. Agenda テストの良さについて 「良いテスト」とは 良いテストを書けるようになるには 私の経験を踏まえて まとめ
8. 01 テストの良さについて
9. テストの目的 高品質なソフトウェアを提供するため、潜在的な不具合を早期に 検出・修正して信頼性を担保すること • 欠陥の発見・修正 ◦ バグをリリース前に取り除き、障害リスクを軽減する • 品質・妥当性の保証 ◦ 期待する要件を満たしていること
10. 手動テスト 画面を人間が操作して、期待通り動いているか検証する
11. 自動テスト プログラミングにおいて、自動テストはWebサービスの品質を確保するための重要 な手法です。 自動テストを使うと、プログラムの動作を自動的にチェックするテストコードを書くこと ができます。 プログラムに変更を加えた後でも、以前の機能が正しく動作するかどうかを素早く確 認することができます。 より引用
12. 開発者視点の良さ • 動くドキュメントを残せる • テストで挙動が担保できているので、安心できる ◦ リファクタリングがしやすい ◦ 追加開発時にデグレが起きていないことが検証できる 守り
13. 開発者視点の良さ • プロダクションコードがきれいになる ◦ テストがしづらい場合、設計に問題がある • 開発スピードUP ◦ 「テストが通っているからヨシ！」でどんどんリリースできる 攻め
14. 開発者視点の良さ 「質とスピード」より引用 🦁 質とスピードはトレードオフじゃない！
15. 02 「良いテスト」とは
16. 「良いテスト」とは • 落ちるべきときに落ちるテスト • 可読性が高い • 適切なスコープ・量
17. 「良いテスト」とは • 落ちるべきときに落ちるテスト • 可読性が高い • 適切なスコープ・量
18. テストカバレッジ def calc(n) if n >= 5 n * 2 else n end end RSpec.describe 'calc' do context 'nが5の場合' do it '10を返す' do expect(calc(5)).to eq 10 end end context 'nが4の場合' do it '4を返す' do expect(calc(4)).to eq 4 end end end プロダクションコードのテスト網羅率を示す
19. テストカバレッジ def calc(n) if n >= 5 n * 2 else n end end RSpec.describe 'calc' do context 'nが5の場合' do it '10を返す' do expect(calc(5)).to eq 10 end end end プロダクションコードのテスト網羅率を示す テストカバレッジを上げて、それぞれのロジックをテストしよう！
20. テストカバレッジ def calc(n) if n >= 5 n * 2 else n end end RSpec.describe 'calc' do context 'nが5の場合' do it '数値を返すこと' do expect(calc(5)).to be_a(Integer) end end context 'nが4の場合' do it '数値を返すこと' do expect(calc(4)).to be_a(Integer) end end end 「テストカバレッジが高い = 適切にテストできている」とは限らない
21. 「良いテスト」とは • 落ちるべきときに落ちるテスト • 可読性が高い • 適切なスコープ・量
22. 「悪いテスト」とは RSpec.describe 'fizzbuzz' do it '期待する値を返すこと' do expect(fizzbuzz(1)).to eq(1) expect(fizzbuzz(3)).to eq("Fizz") expect(fizzbuzz(5)).to eq("Buzz") expect(fizzbuzz(7)).to eq(7) expect(fizzbuzz(9)).to eq("Fizz") expect(fizzbuzz(30)).to eq("FizzBuzz") end end • itの文章だけを読んでも仕様がわからない • テストケースにまとまりがなく読みづらい
23. 「良いテスト」とは RSpec.describe 'fizzbuzz' do context 'nが3で割り切れる場合' do it '"Fizz"を返す' do expect(fizzbuzz(3)).to eq("Fizz") end end context 'nが5で割り切れる場合' do it '"Buzz"を返す' do expect(fizzbuzz(5)).to eq("Buzz") end end context 'nが3でも5でも割り切れる場合' do it '"FizzBuzz"を返す' do expect(fizzbuzz(15)).to eq("FizzBuzz") end end context 'nが3でも5でも割り切れない場合' do it '数値をそのまま返す' do expect(fizzbuzz(7)).to eq(7) end end end • contextとitの文章を読むだけで仕 様がわかる • contextで適切にテストケースを分 けている
24. 「良いテスト」とは • 落ちるべきときに落ちるテスト • 可読性が高い • 適切なスコープ・量
25. テストの種類 関数やメソッドの単位でテストを行う 単体テスト (Unit Test) 統合テスト (Integration Test) E2Eテスト (End-to-End Test) 複数のモジュールの連携した動作を検証する ユーザー視点で開始から終了までの処理フローをテストする Model Spec Request Spec System Spec
26. 単体テスト 統合テスト E2Eテスト テストピラミッド テスティングトロフィー E2Eテスト 統合テスト 単体テスト 静的テスト テストの種類
27. 「良いテスト」とは • 落ちるべきときに落ちるテスト • 可読性が高い • 適切なスコープ・量 ◦ どのテストを厚くすべきかはプロダクトによって違う ▪ フレームワーク ▪ アーキテクチャ ▪ ドメイン
28. 良いテストを書けるようにな るには 03
29. 良いテストを書けるようになるには とにかく書く
30. 良いテストを書けるようになるには • 自分が書いたテストが「良いテスト」だったかはすぐにはわからない ◦ 自分が書いたコードの保守をする中で、小さな失敗を重ねて理解す る • どのテストを厚くするかの判断には、アーキテクチャやドメインの理解が 必要 とにかく書く 量
31. 良いテストを書けるようになるには • テストコードは自分が仕様をどれだけ理解しているかを表すもの ◦ 後世に残したいドキュメントを書こう • プロダクションコードより甘く見られがちで、コピペで数をこなすことも できる… 「良いテスト」について考え続ける 本来は、プロダクションコードよりテストコードの質が大事！！ 質
32. 考えていると、たまに「解」が見つかる 自分のモヤモヤが解決する思想に出会える • RSpec スタイルガイド • 『単体テストの考え方/使い方』
33. 04 私の経験を踏まえて
34. 自分のテストの変遷 RUNTEQ在学中 サービス開発時 1社目 2社目
35. 自分のテストの変遷 RUNTEQ在学中 サービス開発時 1社目 2社目 • RSpec編でテストと出会う • Railsの書き方との違いに苦戦 ◦ よくわからず、サンプルコードを真似するだけ • カリキュラムの自動チェックではこれを使っていたの かという気づき
36. 自分のテストの変遷 RUNTEQ在学中 サービス開発時 1社目 2社目 • テストはまとめて書けばいいという考えから、最初は テスト0で実装を始める • 途中でテストを書き始めるが、実装とテストコードど ちらが間違っているのかわからず混乱 • 最終的にはテストカバレッジ97% ◦ でも、そこまで「良いテスト」ではなかった
37. 自分のテストの変遷 RUNTEQ在学中 サービス開発時 1社目 2社目 • TDD Boot Camp 2020 Onlineに参加 ◦ 現役エンジニアとペアプロしたいという動機 ◦ t_wadaさんの基調講演（ライブコーディング） ▪ TODOリストを作って小さく実装していく ▪ レッド→グリーン→リファクタリングの流れ
38. 自分のテストの変遷 RUNTEQ在学中 サービス開発時 1社目 2社目 • 入社時はテストは最低限書いている程度 • 業務で出すバグは肝の冷えが違う ◦ 守るためにテストする意識の高まり • テストカバレッジ向上プロジェクトにより、テストカバ レッジが32%→85%にUP ◦ テストを書くことでバグを見つけたり、リファクタリ ングがしやすくなることを実感
39. 自分のテストの変遷 RUNTEQ在学中 サービス開発時 1社目 2社目 • 面接時にテストに対する意識を評価される • 実装コードとテストコードはセットが基本 • タスク分解を重要視 • 『単体テストの考え方/使い方』を輪読会で読む to be continued…
40. 05 まとめ
41. まとめ • 良いテストは、サービスの品質を高め開発スピードを上げる • 良いテスト＝落ちるべきときに落ちるテスト • 最適なテストはドメインやフェーズによって違う • 探求しつつ、とにかく書く • 大事なのは 技術よりも意識 「良いテスト」について 良いテストを書けるようになるには
42. 今日からできるアクション • 今書いているプロダクションコードに「守る」テストを書いてみる • 他の人が書いたテストコードを読んで、自分ならどう書くか考える • 直近出たバグの再現コードを書いてみる
43. Thank You!
44. 参考資料 • https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2 023-tokyo-edition • https://swet.dena.com/entry/2023/11/13/170000 • https://github.com/willnet/rspec-style-guide • https://book.mynavi.jp/ec/products/detail/id=134252