堅牢なフロントエンドテスト基盤を構築するために行った取り組み

Transcript

1. 2025.11.30 Shogo Fukami 堅牢なフロントエンドテスト基盤を構築する ために⾏った取り組み フロントエンドカンファレンス関西 2025
2. ⾃⼰紹介 略歴 複数の⼤⼿メガベンチャー、スタートアップを経て 昨年10⽉にカナリーへジョイン 直近はフロントエンドエンジニアの業務を兼務しな がらSRE周りの業務も並⾏して実施 深美 翔悟 / Shogo Fukami 株式会社カナリー 『CANARY』テクニカルリードエンジニア 直近の出来事 温泉サウナが趣味で週2回ぐらいは⾏って息抜きをしています フロントエンドエンジニアの業務とSRE周りの業務を並⾏して実施 つぶやき 本⽇は東京から参加させていただきました 関⻄出⾝で関⻄弁を交えながら話していきたい
4. BtoC/BtoB両軸でプロダクトを展開 *アプリ評価: iOSおよびGooglePlayにおける主要部屋探しアプリのユーザー評価(2022年11⽉data.ai社調査)。 ‧BtoC 不動産マーケットプレイス｢カナリー｣ ‧アプリ版 累計DL数 500万 (Web版もあります！) ‧カテゴリ内ユーザー評価No.1(App Store ★4.8)* ‧TVCMも全国で放映 ‧BtoB 不動産仲会社向けSaaS｢カナリークラウ ド｣ ‧累計利⽤者数 200万⼈を突破 ‧後発ながら、全国の地⽅⼤⼿企業様を軸に急成 ⻑
5. アジェンダ 1.なぜフロントエンドテストを書くべきなのか 2.テスト基盤策定 3.テストガイドライン策定 4.AIを使⽤したテスト実装 5.まとめ 実際の取り組みと⼯夫したポイントを交えてお話します！
6. みなさん!! フロントエンドのテスト書いてますか？
7. 背景 / 課題 テストはあったもののユニットテスト (実装より)が多く、重要な ところがカバーできていなかった どこに何をテスト実装すればいいかわからない 実装していたら別のコンポーネントが消えてた 8割くらい発⽣しているバグはテストでカバーできるもの etc..
8. なぜフロントエンドテストを 書くべきなのか
9. アプリケーションの"⼊り⼝"であり 売上に直結するため
10. アプリケーションの"⼊り⼝"であり売上に直結 フロントエンドはアプリケーションの⼊り⼝ UI崩れ/ボタン不具合 = 離脱‧機会損失 toC: ユーザー離脱‧売上減少 toB: 繁忙期に利⽤不能 → 数百万円の損失も フロントエンドの不具合はビジネスに直結するため テストは書かなければならない！
11. テスト基盤の策定
12. 何をテストすればいいのか？
13. テストの対象を絞る
14. テストの対象を絞る 全部テストするのは⾮現実的 画⾯数が多い メンテコストが爆増 費⽤対効果が悪い テストは "選択と集中" が必須 すべてを守ることはできない "どこが壊れると最も困るか" を明確にする必要がある テストは"すべて"ではなく"重要な部分"に集中すべき
15. テスト対象はどのようにして絞るのか？
16. テスト対象はプロダクトから逆算する
17. テスト対象はプロダクトから逆算する テスト対象の選定はプロダクトを理解することから始まる テストの⽬的は "アプリが動いていること" ではない プロダクト価値が毀損されないこと 売上につながる導線はどこか？ どこが壊れると致命的なのか？ ユーザーは何に価値を感じるのか？
18. CANARYのビジネスモデル
19. CANARYのビジネスモデル エンドユーザー 物件を探している⼈ 物件検索 問い合わせ送信 CANARY BtoC不動産マーケットプレイス 仲介会社 物件を紹介する不動産会社 成果報酬(fee) CANARYはユーザーがお問い合わせに成功した仲介会社から成果報酬を得る
20. プロダクトで最も重要な 導線をテストする
21. ビジネスで最も重要な導線をテストする ビジネス価値に直結する最重要導線 トップ 検索 物件詳細 お問い合わせ 完了 テスト戦略：この⼀連の導線の画⾯を確実に守る 抽出した導線を中⼼にテストを集中させる！
22. テストガイドラインの策定
23. なぜテストガイドラインが必要なのか？
24. なぜテストガイドラインが必要なのか？（理由） これからは「AIにテストを書かせ、⼈がレビュー」する時代 スタイルがバラバラになると、 可読性低下 メンテナンスコスト増⼤ 共通のガイドラインがないと、テストが脆くなる ⼈とAIの両⽅が理解できる共通フォーマットが必要
25. なぜテストガイドラインが必要なのか？（⽬指す状態） 誰が書いても同じ品質 壊れにくく保守しやすいテスト テストの書き⽅を統⼀することで、⼈間とAIが協調できる環境を整える
26. ガイドライン策定（全体像）
27. ガイドライン策定プロセス（全体像） ガイドラインは2つの柱で構成：テストの層とスタイルを明確に定義 ① Testing Trophy（レイヤー） テストを"どの層に書くか" ② BDD / GWT（スタイル） テストを"どう書くか" 「どの層に」「どう書くか」を定義する
28. Testing Trophy のおさらい（どの層に書く？） Testing Trophy（Kent C. Dodds） なぜ Integration 中⼼？ E2E：少なく Integration：厚く Unit：必要なものに最⼩限 複数コンポーネントが組み合わさって初めて動く UI が多い E2Eより軽くて安定 Unitよりユーザー体験に近い 参考⽂献：The Testing Trophy and Testing Classifications フロントエンドでは、Integration テストが最も費⽤対効果が⾼い
29. CANARYにおけるインテグレーションテスト 構成：package-by-feature（機能単位でのパッケージ構成） 実装区分：pages = 画⾯、components = 構成要素 テスト⽅針：画⾯単位でのテスト = ユーザー体験に近い 重点：pagesを中⼼にインテグレーションテストを記述 構造例： features/ └ search/ ├─ pages/ └─ components/
30. 補⾜：ユニットテストが必要なケース 複雑なビジネスロジックをもつ Custom Hooks 外部ライブラリを含んだユーティリティ関数 依存関係が多い処理やパフォーマンス重視のロジック UIと切り離して保守性を上げる
31. テストをどう書くか？
32. BDDスタイルでテストを書く
33. BDDとは（どう書くか） BDD（Behavior Driven Development）とは、「このアプリはどう振る舞うべき か？」を⾃然⾔語で記述し、仕様‧テスト‧ドキュメントを⼀体化する⼿法 ソフトウェア開発において「システムの振る舞い」に焦点を当てた開発⼿法です。従来 のテスト駆動開発（TDD）を発展させた⼿法として、2003年に Daniel Terhorst-North ⽒によって提唱されました。 参考⽂献：Dan North "Introducing BDD"
34. BDDのポイント 実装に依存しない 内部実装が変わってもテストが壊れにくい ユーザー操作そのままのシナリオ 読みやすく意図が伝わる で記述 振る舞いに焦点を当てることで、 意図が明確で⻑期的に保守しやすいテストを実現 Good 👍 ex) ユーザーはお問い合わせ項⽬を⼊⼒してお問い合わせ確認ページへ遷移できる
35. どうテストを構造化する？
36. GWT（Given-When-Then）で構造化
37. GWT（Given-When-Then）とは （どう書く？） Given-When-Then パターンは、BDD（振る舞い）駆動開発の⼀部として開発さ れた、テストを構造的に表す⼿法。 Daniel Terhorst-North と Chris Matts によって開発された構造化アプローチです。 参考⽂献：Martin Fowler: Given-When-Then
38. GWT（Given-When-Then）のポイント Given（前提条件） テストが開始する時点での初期状態を明確に定義します。 例）フォームが初期表⽰されている、ユーザーがログイン済み、特定のデータが存在する
39. GWT（Given-When-Then）のポイント When（操作） テスト対象のユーザーアクションを明確に定義します。 例）ボタンをクリック、フォームに⼊⼒、画⾯をスクロール、要素をドラッグ
40. GWT（Given-When-Then）のポイント Then（期待結果） 操作の結果として期待される状態を明確に定義します。 例）画⾯が遷移する、エラーメッセージが表⽰される、データが更新される
41. AIを使⽤したテスト実装
42. 前提
43. 前提 ‒ Try AI Budget 制度 制度のポイント 開発本部の正社員40名を対象に 1⼈あたり⽉額$200まで会社負担で AIツールを⾃由に試せる制度 「AIをためらわず試す⽂化」をつくることを ⽬的としています。 利⽤できるAIツール例 GitHub Copilot Claude Code ChatGPT, Codex Cursor Devin AQUA Voice そのほか新しいツールも随時追加中！ 「試して学ぶ環境を保証することで、組織全体のAI活⽤を加速」
44. 今回使⽤するAIとモデル AI: Claude Code（Opus 4.1） 選んだ理由: チームメンバーの9割が使⽤ サブエージェントを使える
45. どうAIにテストを書かせたいか？
46. テストケースの⼊⼒で AIにテストを書かせたい
47. 検証するページ 例：物件を路線‧駅から探すページ ユーザーは東京駅を選択して検索結果ページ へ遷移できる ユーザーは東京駅を選択して検索条件追加 ページへ遷移できる ユーザーは東海道新幹線を選択して検索結果 ページへ遷移できる ユーザーは複数都道府県の路線で他県の 駅⼀覧が折りたたまれている駅をクリッ クして検索結果画⾯へ遷移する このテストケースをそのままプロンプトに⼊⼒する！
48. プロンプト
50. 期待しているコード
51. 出⼒結果
52. describeがネストしている... セクション取るだけにgetAllByTextを使用 している... 駅の要素はgetByRoleで取得できそうな のにcheckboxを全て取得して東京駅を 検索している.... チェックボックスがあるかないかなど実 装のテストを書いている.... 期待していたテストコードとは程遠い
53. そうだ カスタムサブエージェント、 使おう。
54. Claude Codeのカスタムサブエージェントとは 特定のタスクや役割に特化して動作する、⼩さな独⽴したAIエージェントのこと コンテキストが⼤きくなるにつれて、LLMは迷ったり焦点を失ったりする可能性 が⾼くなるため、メインとは別のコンテキスト‧設定‧権限を持ち、専⾨的な処 理を担当することで、作業を分担し効率化できる。 ⇨ 要は、メインで使⽤しているコンテキストが肥⼤化するのを解決してLLMが ⽣成するコードの品質をあげましょうという話。 /agents コマンドで作成可 能。
55. テスト専⾨のカスタムサブエージェントを作成 細かい内容やベストプラクティスを記載したテスト専⾨職を作った
56. Plan modeで調査した内容を サブエージェントに投げてテストを実装
58. 出⼒結果
59. 良くなった点 前提‧操作‧期待が明確に分離されている 実装のテストではなく、振る舞いにフォーカ スしたテストが⽣成されている 要素の取得がRoleの取得になっている
60. まとめ（AI × ガイドライン） ほとんど修正不要なレベルで理想のコードが⽣成されるようになってきた ドキュメントの適宜チューニングで⽣成品質を⾼める努⼒は必要 プロダクトに最適な良いガイドラインの策定が不可⽋ 技術⼒の偏りがあっても均質なコード品質を担保できる AIを使いこなす鍵は、⼈間による 「ガイドラインの設計」と「ドキュメントの継続的な改善」が必要 AIでテスト実装するにしても⼈間が最初の段階でいつくかテストを書く必要はありそう
61. まとめ
62. まとめ テストは“全部書く”必要はない ビジネスモデルから “最重要導線” を特定する テストガイドラインで「どの層に」「どう書くか」を定義する AIにコードを書かせることで均質なコード品質を担保しよう
63. ご清聴ありがとうございました！