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

by Shogo Fukami

Slide 1

Slide 1 text

2025.11.30 Shogo Fukami 堅牢なフロントエンドテスト基盤を構築するために⾏った取り組みフロントエンドカンファレンス関西 2025

Slide 2

Slide 2 text

⾃⼰紹介略歴複数の⼤⼿メガベンチャー、スタートアップを経て昨年10⽉にカナリーへジョイン直近はフロントエンドエンジニアの業務を兼務しながらSRE周りの業務も並⾏して実施深美翔悟 / Shogo Fukami 株式会社カナリー『CANARY』テクニカルリードエンジニア直近の出来事温泉サウナが趣味で週2回ぐらいは⾏って息抜きをしていますフロントエンドエンジニアの業務とSRE周りの業務を並⾏して実施つぶやき本⽇は東京から参加させていただきました関⻄出⾝で関⻄弁を交えながら話していきたい

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

BtoC/BtoB両軸でプロダクトを展開 *アプリ評価: iOSおよびGooglePlayにおける主要部屋探しアプリのユーザー評価(2022年11⽉data.ai社調査)。 ‧BtoC 不動産マーケットプレイス｢カナリー｣ ‧アプリ版累計DL数 500万 (Web版もあります！) ‧カテゴリ内ユーザー評価No.1(App Store ★4.8)* ‧TVCMも全国で放映 ‧BtoB 不動産仲会社向けSaaS｢カナリークラウド｣ ‧累計利⽤者数 200万⼈を突破 ‧後発ながら、全国の地⽅⼤⼿企業様を軸に急成⻑

Slide 5

Slide 5 text

アジェンダ 1.なぜフロントエンドテストを書くべきなのか 2.テスト基盤策定 3.テストガイドライン策定 4.AIを使⽤したテスト実装 5.まとめ実際の取り組みと⼯夫したポイントを交えてお話します！

Slide 6

Slide 6 text

みなさん!! フロントエンドのテスト書いてますか？

Slide 7

Slide 7 text

背景 / 課題テストはあったもののユニットテスト (実装より)が多く、重要なところがカバーできていなかったどこに何をテスト実装すればいいかわからない実装していたら別のコンポーネントが消えてた 8割くらい発⽣しているバグはテストでカバーできるもの etc..

Slide 8

Slide 8 text

なぜフロントエンドテストを書くべきなのか

Slide 9

Slide 9 text

アプリケーションの"⼊り⼝"であり売上に直結するため

Slide 10

Slide 10 text

アプリケーションの"⼊り⼝"であり売上に直結フロントエンドはアプリケーションの⼊り⼝ UI崩れ/ボタン不具合 = 離脱‧機会損失 toC: ユーザー離脱‧売上減少 toB: 繁忙期に利⽤不能 → 数百万円の損失もフロントエンドの不具合はビジネスに直結するためテストは書かなければならない！

Slide 11

Slide 11 text

テスト基盤の策定

Slide 12

Slide 12 text

何をテストすればいいのか？

Slide 13

Slide 13 text

テストの対象を絞る

Slide 14

Slide 14 text

テストの対象を絞る全部テストするのは⾮現実的画⾯数が多いメンテコストが爆増費⽤対効果が悪いテストは "選択と集中" が必須すべてを守ることはできない "どこが壊れると最も困るか" を明確にする必要があるテストは"すべて"ではなく"重要な部分"に集中すべき

Slide 15

Slide 15 text

テスト対象はどのようにして絞るのか？

Slide 16

Slide 16 text

テスト対象はプロダクトから逆算する

Slide 17

Slide 17 text

テスト対象はプロダクトから逆算するテスト対象の選定はプロダクトを理解することから始まるテストの⽬的は "アプリが動いていること" ではないプロダクト価値が毀損されないこと売上につながる導線はどこか？どこが壊れると致命的なのか？ユーザーは何に価値を感じるのか？

Slide 18

Slide 18 text

CANARYのビジネスモデル

Slide 19

Slide 19 text

CANARYのビジネスモデルエンドユーザー物件を探している⼈物件検索問い合わせ送信 CANARY BtoC不動産マーケットプレイス仲介会社物件を紹介する不動産会社成果報酬(fee) CANARYはユーザーがお問い合わせに成功した仲介会社から成果報酬を得る

Slide 20

Slide 20 text

プロダクトで最も重要な導線をテストする

Slide 21

Slide 21 text

ビジネスで最も重要な導線をテストするビジネス価値に直結する最重要導線トップ検索物件詳細お問い合わせ完了テスト戦略：この⼀連の導線の画⾯を確実に守る抽出した導線を中⼼にテストを集中させる！

Slide 22

Slide 22 text

テストガイドラインの策定

Slide 23

Slide 23 text

なぜテストガイドラインが必要なのか？

Slide 24

Slide 24 text

なぜテストガイドラインが必要なのか？（理由）これからは「AIにテストを書かせ、⼈がレビュー」する時代スタイルがバラバラになると、可読性低下メンテナンスコスト増⼤共通のガイドラインがないと、テストが脆くなる⼈とAIの両⽅が理解できる共通フォーマットが必要

Slide 25

Slide 25 text

なぜテストガイドラインが必要なのか？（⽬指す状態）誰が書いても同じ品質壊れにくく保守しやすいテストテストの書き⽅を統⼀することで、⼈間とAIが協調できる環境を整える

Slide 26

Slide 26 text

ガイドライン策定（全体像）

Slide 27

Slide 27 text

ガイドライン策定プロセス（全体像）ガイドラインは2つの柱で構成：テストの層とスタイルを明確に定義 ① Testing Trophy（レイヤー）テストを"どの層に書くか" ② BDD / GWT（スタイル）テストを"どう書くか" 「どの層に」「どう書くか」を定義する

Slide 28

Slide 28 text

Testing Trophy のおさらい（どの層に書く？） Testing Trophy（Kent C. Dodds）なぜ Integration 中⼼？ E2E：少なく Integration：厚く Unit：必要なものに最⼩限複数コンポーネントが組み合わさって初めて動く UI が多い E2Eより軽くて安定 Unitよりユーザー体験に近い参考⽂献：The Testing Trophy and Testing Classiﬁcations フロントエンドでは、Integration テストが最も費⽤対効果が⾼い

Slide 29

Slide 29 text

CANARYにおけるインテグレーションテスト構成：package-by-feature（機能単位でのパッケージ構成）実装区分：pages = 画⾯、components = 構成要素テスト⽅針：画⾯単位でのテスト = ユーザー体験に近い重点：pagesを中⼼にインテグレーションテストを記述構造例： features/ └ search/ ├─ pages/ └─ components/

Slide 30

Slide 30 text

補⾜：ユニットテストが必要なケース複雑なビジネスロジックをもつ Custom Hooks 外部ライブラリを含んだユーティリティ関数依存関係が多い処理やパフォーマンス重視のロジック UIと切り離して保守性を上げる

Slide 31

Slide 31 text

テストをどう書くか？

Slide 32

Slide 32 text

BDDスタイルでテストを書く

Slide 33

Slide 33 text

BDDとは（どう書くか） BDD（Behavior Driven Development）とは、「このアプリはどう振る舞うべきか？」を⾃然⾔語で記述し、仕様‧テスト‧ドキュメントを⼀体化する⼿法ソフトウェア開発において「システムの振る舞い」に焦点を当てた開発⼿法です。従来のテスト駆動開発（TDD）を発展させた⼿法として、2003年に Daniel Terhorst-North ⽒によって提唱されました。参考⽂献：Dan North "Introducing BDD"

Slide 34

Slide 34 text

BDDのポイント実装に依存しない内部実装が変わってもテストが壊れにくいユーザー操作そのままのシナリオ読みやすく意図が伝わるで記述振る舞いに焦点を当てることで、意図が明確で⻑期的に保守しやすいテストを実現 Good 👍 ex) ユーザーはお問い合わせ項⽬を⼊⼒してお問い合わせ確認ページへ遷移できる

Slide 35

Slide 35 text

どうテストを構造化する？

Slide 36

Slide 36 text

GWT（Given-When-Then）で構造化

Slide 37

Slide 37 text

GWT（Given-When-Then）とは（どう書く？） Given-When-Then パターンは、BDD（振る舞い）駆動開発の⼀部として開発された、テストを構造的に表す⼿法。 Daniel Terhorst-North と Chris Matts によって開発された構造化アプローチです。参考⽂献：Martin Fowler: Given-When-Then

Slide 38

Slide 38 text

GWT（Given-When-Then）のポイント Given（前提条件）テストが開始する時点での初期状態を明確に定義します。例）フォームが初期表⽰されている、ユーザーがログイン済み、特定のデータが存在する

Slide 39

Slide 39 text

GWT（Given-When-Then）のポイント When（操作）テスト対象のユーザーアクションを明確に定義します。例）ボタンをクリック、フォームに⼊⼒、画⾯をスクロール、要素をドラッグ

Slide 40

Slide 40 text

GWT（Given-When-Then）のポイント Then（期待結果）操作の結果として期待される状態を明確に定義します。例）画⾯が遷移する、エラーメッセージが表⽰される、データが更新される

Slide 41

Slide 41 text

AIを使⽤したテスト実装

Slide 42

Slide 42 text

前提

Slide 43

Slide 43 text

前提 ‒ Try AI Budget 制度制度のポイント開発本部の正社員40名を対象に 1⼈あたり⽉額$200まで会社負担で AIツールを⾃由に試せる制度「AIをためらわず試す⽂化」をつくることを⽬的としています。利⽤できるAIツール例 GitHub Copilot Claude Code ChatGPT, Codex Cursor Devin AQUA Voice そのほか新しいツールも随時追加中！「試して学ぶ環境を保証することで、組織全体のAI活⽤を加速」

Slide 44

Slide 44 text

今回使⽤するAIとモデル AI: Claude Code（Opus 4.1）選んだ理由: チームメンバーの9割が使⽤サブエージェントを使える

Slide 45

Slide 45 text

どうAIにテストを書かせたいか？

Slide 46

Slide 46 text

テストケースの⼊⼒で AIにテストを書かせたい

Slide 47

Slide 47 text

検証するページ例：物件を路線‧駅から探すページユーザーは東京駅を選択して検索結果ページへ遷移できるユーザーは東京駅を選択して検索条件追加ページへ遷移できるユーザーは東海道新幹線を選択して検索結果ページへ遷移できるユーザーは複数都道府県の路線で他県の駅⼀覧が折りたたまれている駅をクリックして検索結果画⾯へ遷移するこのテストケースをそのままプロンプトに⼊⼒する！

Slide 48

Slide 48 text

プロンプト

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

期待しているコード

Slide 51

Slide 51 text

出⼒結果

Slide 52

Slide 52 text

describeがネストしている... セクション取るだけにgetAllByTextを使用している... 駅の要素はgetByRoleで取得できそうなのにcheckboxを全て取得して東京駅を検索している.... チェックボックスがあるかないかなど実装のテストを書いている.... 期待していたテストコードとは程遠い

Slide 53

Slide 53 text

そうだカスタムサブエージェント、使おう。

Slide 54

Slide 54 text

Claude Codeのカスタムサブエージェントとは特定のタスクや役割に特化して動作する、⼩さな独⽴したAIエージェントのことコンテキストが⼤きくなるにつれて、LLMは迷ったり焦点を失ったりする可能性が⾼くなるため、メインとは別のコンテキスト‧設定‧権限を持ち、専⾨的な処理を担当することで、作業を分担し効率化できる。 ⇨ 要は、メインで使⽤しているコンテキストが肥⼤化するのを解決してLLMが⽣成するコードの品質をあげましょうという話。 /agents コマンドで作成可能。

Slide 55

Slide 55 text

テスト専⾨のカスタムサブエージェントを作成細かい内容やベストプラクティスを記載したテスト専⾨職を作った

Slide 56

Slide 56 text

Plan modeで調査した内容をサブエージェントに投げてテストを実装

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

出⼒結果

Slide 59

Slide 59 text

良くなった点前提‧操作‧期待が明確に分離されている実装のテストではなく、振る舞いにフォーカスしたテストが⽣成されている要素の取得がRoleの取得になっている

Slide 60

Slide 60 text

まとめ（AI × ガイドライン）ほとんど修正不要なレベルで理想のコードが⽣成されるようになってきたドキュメントの適宜チューニングで⽣成品質を⾼める努⼒は必要プロダクトに最適な良いガイドラインの策定が不可⽋技術⼒の偏りがあっても均質なコード品質を担保できる AIを使いこなす鍵は、⼈間による「ガイドラインの設計」と「ドキュメントの継続的な改善」が必要 AIでテスト実装するにしても⼈間が最初の段階でいつくかテストを書く必要はありそう

Slide 61

Slide 61 text

まとめ

Slide 62

Slide 62 text

まとめテストは“全部書く”必要はないビジネスモデルから “最重要導線” を特定するテストガイドラインで「どの層に」「どう書くか」を定義する AIにコードを書かせることで均質なコード品質を担保しよう

Slide 63

Slide 63 text

ご清聴ありがとうございました！