Tweet
Tweet

Slide 1

Slide 1 text

テストって楽しい！ 開発を加速させるテストの魅力 2025/4/26 RUNTEQ.rb 遠藤 薫（END）

Slide 2

Slide 2 text

self.introduction 遠藤 薫（END） RUNTEQ 6期生（2020年1月入学） 2020年9月にエンジニアとして就職する 2023年2月に株式会社ファインディ入社 技術スタックは Rails, React 趣味はリアル脱出ゲーム・ボードゲーム @aiandrox

Slide 3

Slide 3 text

テストといえば？

Slide 4

Slide 4 text

テストといえば？ RSpec t_wadaさん

Slide 5

Slide 5 text

テストに対する実態調査 「テスト」、書いていますか？　

Slide 6

Slide 6 text

テストに対する実態調査 「良いテスト」、書いていますか？　

Slide 7

Slide 7 text

Agenda テストの良さについて 「良いテスト」とは 良いテストを書けるようになるには 私の経験を踏まえて まとめ

Slide 8

Slide 8 text

01 テストの良さについて

Slide 9

Slide 9 text

テストの目的 高品質なソフトウェアを提供するため、潜在的な不具合を早期に 検出・修正して信頼性を担保すること ● 欠陥の発見・修正 ○ バグをリリース前に取り除き、障害リスクを軽減する ● 品質・妥当性の保証 ○ 期待する要件を満たしていること

Slide 10

Slide 10 text

手動テスト 画面を人間が操作して、期待通り動いているか検証する

Slide 11

Slide 11 text

自動テスト プログラミングにおいて、自動テストはWebサービスの品質を確保するための重要 な手法です。 自動テストを使うと、プログラムの動作を自動的にチェックするテストコードを書くこと ができます。 プログラムに変更を加えた後でも、以前の機能が正しく動作するかどうかを素早く確 認することができます。 より引用

Slide 12

Slide 12 text

開発者視点の良さ ● 動くドキュメントを残せる ● テストで挙動が担保できているので、安心できる ○ リファクタリングがしやすい ○ 追加開発時にデグレが起きていないことが検証できる 守り

Slide 13

Slide 13 text

開発者視点の良さ ● プロダクションコードがきれいになる ○ テストがしづらい場合、設計に問題がある ● 開発スピードUP ○ 「テストが通っているからヨシ！」でどんどんリリースできる 攻め

Slide 14

Slide 14 text

開発者視点の良さ 「質とスピード」より引用 🦁 質とスピードはトレードオフじゃない！

Slide 15

Slide 15 text

02 「良いテスト」とは

Slide 16

Slide 16 text

「良いテスト」とは ● 落ちるべきときに落ちるテスト ● 可読性が高い ● 適切なスコープ・量

Slide 17

Slide 17 text

「良いテスト」とは ● 落ちるべきときに落ちるテスト ● 可読性が高い ● 適切なスコープ・量

Slide 18

Slide 18 text

テストカバレッジ 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 プロダクションコードのテスト網羅率を示す

Slide 19

Slide 19 text

テストカバレッジ 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 プロダクションコードのテスト網羅率を示す テストカバレッジを上げて、それぞれのロジックをテストしよう！

Slide 20

Slide 20 text

テストカバレッジ 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 「テストカバレッジが高い = 適切にテストできている」とは限らない

Slide 21

Slide 21 text

「良いテスト」とは ● 落ちるべきときに落ちるテスト ● 可読性が高い ● 適切なスコープ・量

Slide 22

Slide 22 text

「悪いテスト」とは 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の文章だけを読んでも仕様がわからない ● テストケースにまとまりがなく読みづらい

Slide 23

Slide 23 text

「良いテスト」とは 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で適切にテストケースを分 けている

Slide 24

Slide 24 text

「良いテスト」とは ● 落ちるべきときに落ちるテスト ● 可読性が高い ● 適切なスコープ・量

Slide 25

Slide 25 text

テストの種類 関数やメソッドの単位でテストを行う 単体テスト (Unit Test) 統合テスト (Integration Test) E2Eテスト (End-to-End Test) 複数のモジュールの連携した動作を検証する ユーザー視点で開始から終了までの処理フローをテストする Model Spec Request Spec System Spec

Slide 26

Slide 26 text

単体テスト 統合テスト E2Eテスト テストピラミッド テスティングトロフィー E2Eテスト 統合テスト 単体テスト 静的テスト テストの種類

Slide 27

Slide 27 text

「良いテスト」とは ● 落ちるべきときに落ちるテスト ● 可読性が高い ● 適切なスコープ・量 ○ どのテストを厚くすべきかはプロダクトによって違う ■ フレームワーク ■ アーキテクチャ ■ ドメイン

Slide 28

Slide 28 text

良いテストを書けるようにな るには 03

Slide 29

Slide 29 text

良いテストを書けるようになるには とにかく書く

Slide 30

Slide 30 text

良いテストを書けるようになるには ● 自分が書いたテストが「良いテスト」だったかはすぐにはわからない ○ 自分が書いたコードの保守をする中で、小さな失敗を重ねて理解す る ● どのテストを厚くするかの判断には、アーキテクチャやドメインの理解が 必要 とにかく書く 量

Slide 31

Slide 31 text

良いテストを書けるようになるには ● テストコードは自分が仕様をどれだけ理解しているかを表すもの ○ 後世に残したいドキュメントを書こう ● プロダクションコードより甘く見られがちで、コピペで数をこなすことも できる… 「良いテスト」について考え続ける 本来は、プロダクションコードよりテストコードの質が大事！！ 質

Slide 32

Slide 32 text

考えていると、たまに「解」が見つかる 自分のモヤモヤが解決する思想に出会える ● RSpec スタイルガイド ● 『単体テストの考え方/使い方』

Slide 33

Slide 33 text

04 私の経験を踏まえて

Slide 34

Slide 34 text

自分のテストの変遷 RUNTEQ在学中 サービス開発時 1社目 2社目

Slide 35

Slide 35 text

自分のテストの変遷 RUNTEQ在学中 サービス開発時 1社目 2社目 ● RSpec編でテストと出会う ● Railsの書き方との違いに苦戦 ○ よくわからず、サンプルコードを真似するだけ ● カリキュラムの自動チェックではこれを使っていたの かという気づき

Slide 36

Slide 36 text

自分のテストの変遷 RUNTEQ在学中 サービス開発時 1社目 2社目 ● テストはまとめて書けばいいという考えから、最初は テスト0で実装を始める ● 途中でテストを書き始めるが、実装とテストコードど ちらが間違っているのかわからず混乱 ● 最終的にはテストカバレッジ97% ○ でも、そこまで「良いテスト」ではなかった

Slide 37

Slide 37 text

自分のテストの変遷 RUNTEQ在学中 サービス開発時 1社目 2社目 ● TDD Boot Camp 2020 Onlineに参加 ○ 現役エンジニアとペアプロしたいという動機 ○ t_wadaさんの基調講演（ライブコーディング） ■ TODOリストを作って小さく実装していく ■ レッド→グリーン→リファクタリングの流れ

Slide 38

Slide 38 text

自分のテストの変遷 RUNTEQ在学中 サービス開発時 1社目 2社目 ● 入社時はテストは最低限書いている程度 ● 業務で出すバグは肝の冷えが違う ○ 守るためにテストする意識の高まり ● テストカバレッジ向上プロジェクトにより、テストカバ レッジが32%→85%にUP ○ テストを書くことでバグを見つけたり、リファクタリ ングがしやすくなることを実感

Slide 39

Slide 39 text

自分のテストの変遷 RUNTEQ在学中 サービス開発時 1社目 2社目 ● 面接時にテストに対する意識を評価される ● 実装コードとテストコードはセットが基本 ● タスク分解を重要視 ● 『単体テストの考え方/使い方』を輪読会で読む to be continued…

Slide 40

Slide 40 text

05 まとめ

Slide 41

Slide 41 text

まとめ ● 良いテストは、サービスの品質を高め開発スピードを上げる ● 良いテスト＝落ちるべきときに落ちるテスト ● 最適なテストはドメインやフェーズによって違う ● 探求しつつ、とにかく書く ● 大事なのは 技術よりも意識 「良いテスト」について 良いテストを書けるようになるには

Slide 42

Slide 42 text

今日からできるアクション ● 今書いているプロダクションコードに「守る」テストを書いてみる ● 他の人が書いたテストコードを読んで、自分ならどう書くか考える ● 直近出たバグの再現コードを書いてみる

Slide 43

Slide 43 text

Thank You!

Slide 44

Slide 44 text

参考資料 ● 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