AIのためのテスト戦略 〜TDDが難しいフロントエンド開発でのアプローチ〜

Transcript

1. AIのためのテスト戦略 〜TDDが難しいフロントエンド開発でのアプローチ〜 2025/10/04 横山 隼 ScrumMatsuri 2025
2. 自己紹介 • ディップ株式会社 • 2022年新卒入社 • フロントエンドエンジニア 横山 隼
3. みなさん、AIコーディングはされていますか？🤔
4. されていますよね😌
5. 最近は、AIコーディングが当たり前になってきました
6. 開発スピードは爆発的に速くなりました 🚀
7. とはいえ、まだまだ指示したことと違うことするときがある🤔
8. 関係ないところまで修正に手を出して、
9. 関係ないところまで修正に手を出して、 エラーが出て、
10. 関係ないところまで修正に手を出して、 エラーが出て、 違う治し方して、
11. 関係ないところまで修正に手を出して、 エラーが出て、 違う治し方して、 そうじゃないってなることがある
12. 今回は、AIに開発を任せて、 開発スピードを落とさずにガードレールとなるような
13. フロントエンドテストの取り組み 5つ紹介します
14. 抽象的な大きな取り組みから、 具体的なテクニック的な話まで含まれます
15. チーム状況 🧰 技術スタック TypeScript, React Router v7 🧠 AIコーディング JiraやFigmaをMCP経由で Claude Code に取り込み、実装させる 󰞵 チーム人数 エンジニア3人 少人数ながら AIを活用してスピードと品質の両面を追う
16. FEがBEと通信する層を厚くテストする
17. FEがBEと通信する層を厚くテストする • ビジネス上の重要なロジックが集中しやすい層なので 厚くテストする • テスタブルにするために なるべく純粋なTypeScript関数になるようにする
18. 私のチームではReact Router の Loader/Action関数をBFF層として データ取得、整形、送信、バリデーションなどをしている テストケース抜粋 • 名前・メール・電話番号を正しく入力すると、入力内容が返されること • 応募確認画面で閲覧中に求人が締切になったら、応募エラーになること • 応募ボタン連打しても、二重送信されないこと Loader/Actionをカバレッジ 100%になるように書いている
19. StorybookのcomposeStoriesで 共通コンポーネントをテストする
20. 「フロントエンドのテストを書いていこう！」とすると よくあることとして...🤔
21. it("'Hello World' のテキストが表示されること ", () => { render(<Greeting text={"Hello World"} />); expect(screen.getByText("Hello World")).toBeInTheDocument(); }); export function Greeting({ text }: GreetingProps) { return <p>{text}</p>; } Propsで渡されたテキストを表示するコンポーネントに対して、 テキストが表示されること ➡ 効果の低いテストを過剰に書いてしまう
22. 一方で🤔
23. ➡ ユーザー操作を含むテストは再現するのが難しく、コストが高い // テスト上でスクロール操作ができないので、スクロール量を上書きする const setScrollY = (y: number) => { Object.defineProperty(window, "scrollY", { configurable: true, value: y, }); window.dispatchEvent(new Event("scroll")); }; it("スクロール量が閾値を超えたらナビゲーションバーが表示される", () => { render(<Navbar />); expect(screen.queryByTestId("navbar")).toBeNull(); setScrollY(120); expect(screen.getByTestId("navbar")).toBeInTheDocument(); });
24. すべてのコンポーネントに対して、 テストしようとすると過剰になりがち でも、効果が高いインタラクティブな挙動を テストするのはコストが高い
25. だからこそ、アプリ全体で繰り返し使われる 共通コンポーネントに絞ってテストする
26. だからこそ、アプリ全体で繰り返し使われる 共通コンポーネントに絞ってテストする ➡ StorybookのcomposeStoriesでテストする
27. 📚 composeStories･･･ Storybookのストーリーをテスト環境で利用できる仕組み const meta: Meta<typeof Button> = { title: "Components/Button", component: Button, args: { label: "Click Me" }, }; export default meta; type Story = StoryObj<typeof Button>; export const Primary: Story = { args: { disabled: false }, }; export const Disabled: Story = { args: { disabled: true, label: "Disabled" }, }; it("Primary: ~~~~", async () => { render(<Primary onClick={onClick} />); // 略 expect(onClick).toHaveBeenCalledTimes(1); }); it("Disabled: ~~~~", async () => { render(<Disabled onClick={onClick} />); // 略 expect(onClick).not.toHaveBeenCalled(); }); Storybook テスト
28. 📚 composeStories･･･ Storybookのストーリーをテスト環境で利用できる仕組み const meta: Meta<typeof Button> = { title: "Components/Button", component: Button, args: { label: "Click Me" }, }; export default meta; type Story = StoryObj<typeof Button>; export const Primary: Story = { args: { disabled: false }, }; export const Disabled: Story = { args: { disabled: true, label: "Disabled" }, }; it("Primary: ~~~~", async () => { render(<Primary onClick={onClick} />); // 略 expect(onClick).toHaveBeenCalledTimes(1); }); it("Disabled: ~~~~", async () => { render(<Disabled onClick={onClick} />); // 略 expect(onClick).not.toHaveBeenCalled(); }); Storybook テスト
29. composeStoriesを使うことで... • ストーリーの更新することでテストも同時に更新され、 ストーリーとテストに乖離が起きない • ストーリーごとに「本番と近い環境」で UI を再現できる
30. composeStoriesを使うことで... • ストーリーの更新することでテストも同時に更新され、 ストーリーとテストに乖離が起きない • ストーリーごとに「本番と近い環境」で UI を再現できる ➡ 共通コンポーネントに絞ってテストする
31. AAAパターン
32. Arrange（準備）, Act（実行）, Assert（検証）の 3つセクションに明示的に分けた構成でテストを書く it('2つの正の数を正しく足し算できること', () => { // Arrange (準備): const num1 = 5; const num2 = 3; const expectedSum = 8; // Act (実行): const actualSum = add(num1, num2); // Assert (検証): expect(actualSum).toBe(expectedSum); });
33. AIコーディングするにあたって、細かなルールで書き方を制限して、 表現の自由度を狭めてあげる
34. テストケース名は ユーザー/ビジネス視点で記述する
35. it('応募ボタンを押すと確認画面に進むこと ', () => { ... }); ✅ Good ❌ Bad it('onSubmit が navigate('/confirm') を呼ぶこと', () => { ... }); ユーザーの行動と成果が主語になるように書く
36. ユーザー体験にどうつながるのか🤔を見極めやすくなる ビジネス的な効果の薄いテストを疑うトリガーになる
37. テストファイルはコロケーションする
38. テストファイルは__tests__/とかtests/ に置くのではなく テスト対象のコードの同じディレクトリ配下に置く route/ └── top/ ├── route.tsx └── top.test.tsx ⬅ util/ └── date/ ├── date.test └── date.test.tsx ⬅ tests/ ├── route/ │ ├── top.test.tsx │ └── job-detail.test.tsx └── test/ ├── top.test.tsx └── job-detail.test.tsx ✅ Good ❌ Bad
39. テストをアプリケーションコードとコロケーションすることで、 • 「隣のテストも直す」意識が働き、 テストのメンテが置き去りになりにくい • 関連ファイルが近接していると、AIが文脈を取り込みやすい 人もAIもテストを見失わないようにするために テストはコロケーションする
40. さいごに
41. さいごに • FEがBEを通信する層を厚くテストする • UIは共通コンポーネントに絞ってテストする • 人もAIも迷わないように、書き方・名前・配置を工夫する AIコーディングで開発スピードを上げつつ、テストで品質を支える