フロントエンドテスト導入は「ストーリー」を意識しよう

フロントエンドテスト導入は   「ストーリー」   を意識しよう       三海純(ミカイジュン) 

ミカイジュン   • フリーランスエンジニア   • 趣味: もくもく会、アニメ、ネット麻雀(雀魂)  
• 好きな有名人   ◦ 後藤ひとり   ◦ 陸八魔アル   ◦ 千早愛音  ◦ 八木唯 

キャリア  • 2020年 ~ 2022年   ◦ 正社員: フロントエンドエンジニア  
• 2022年 ~ 2023年   ◦ 正社員: フロントエンド&バックエンドエンジニア   • 現在(2024年)   ◦ フリーランス: Next.js など設計&開発   • 来年(2025年 ~)   ◦ 株式会社ゆめみ正社員として入社予定  

こんな話ありませんか？   • フロントエンドのテストコード書く時間があったら追加開発、改善したい   • フロントエンドのテストで何を導入していいかわからない  

今回は・・・  難しい話は抜きにして   ストーリー形式で   楽しくテストコードの   メリットを紹介！  

補足  テストを書くことが目標になっている時点では、おそらく『今』はフロントエンドのテストを導入するフェーズないと思う  

Storybook   (UIコンポーネントテスト)

export const Default: Story = { play: async ({ canvasElement,
step }) => { const canvas = within(canvasElement); const checkbox = await canvas.findByRole("checkbox"); await step("checkboxクリックでチェックがつくこと ", async () => { await userEvent.click(checkbox); await expect(checkbox).toHaveAttribute("aria-checked", "true"); }); }, }; こんなテストコード

Storybookでテスト必要なシーン   開発初期で   「このコンポーネントずっと使いそう」   と思った時    

テストを書かなかった   ストーリーをご覧ください    

1ヶ月目：リリース準備    突然、クライアントから「チェックボックスがチェックされていない時、ちゃんとエラーメッセージが出ない！」との報告が。  バリデーションが発火しないバグが潜んでいた！焦りながら修正に取りかかるも、他のコードをいじったことで予期せぬ不具合がどんどん出現    
   

2ヶ月目：追加機能の実装   今度はフォームに複数のチェックボックスを追加することに。  「同じコンポーネントだから、簡単にいけるでしょ」と思いきや、またもや未チェック時のエラー表示が効かないどこを直せばいいか全く分からない。      

3ヶ月目：保守フェーズ   新たに加わったメンバーが「チェックボックス、どうなってます？」と質問。   テストがないため仕様確認やバグ再現に手間取る。「あの時、テストを書いてさえいれば…」と後悔するも、すでに遅く、毎回リリース前に手動で大量のチェックを繰り返す羽目に。 

こうならないためにも・・・   長期的なプロダクト開発になるのであればできるだけ早い段階でStorybookでテストコードを導入しよう！     逆に言えば、すでにプロダクトが出来上がっていて保守運用しない場合は他のテストの方がいいかも  

Playwright  

test.describe("UI操作の確認", () => { test("チェックボックスをクリックするとラベルが表示されるか確認 ", async ({ page, })
=> { await page.getByLabel("ラベル1").click(); await page.getByLabel(PREFECTURES.AOMORI).dblclick(); const label = await page.getByLabel("ラベル1"); await expect(label).toBeVisible(); }); }); こんなテストコード

Playwright でテスト必要なシーン   機能が増えて手動テストが多くなり、   開発サイクルに負担が   かかり始めたタイミング  

テストを書かなかった   ストーリーをご覧ください    

リリースして半年後    機能が増え、ユーザー認証やフォーム送信、ダッシュボードのリアルタイム更新などの複雑な操作が増加。手動テストはどんどん煩雑になり、作業負荷が急増。「毎回ログインして全機能を手動で確認するのは限界…」という声が漏れ始める       

機能追加リリース直前の大混乱    本番リリースを目前に、手動テストに追われる日々。新しいチェックボックス機能に不具合が発覚し、修正のたびに他の部分が壊れる状況に。   リリース後、ユーザーから「チェックボックスが動かない」「ダッシュボードが更新されない」などのクレームが殺到。  

こうならないためにも・・・   長期的なプロダクト開発になるとわかった段階で Playwrightでテストコードを導入しよう！     逆に言えば、1stリリース直後の機能がシンプルな状態の時は他のテストの方がいいかも  

いつ書くか？   • Storybook   ◦ コンポーネントの設計時にテストを書き始めるのが理想  • Playwight
  ◦ 機能が安定し、複雑なフローが増えてきたタイミング 

具体例  • Storybook   ◦ 初期のUI設計段階で、コンポーネントがデザインや要件に合っているかを確認したい時   • Playwight
  ◦ 手動テストの負担が増えた時。UIの操作フローが複雑化してきた段階で、自動テストに移行することで開発効率を維持したい時 

結論  プロダクトの「課題」が生まれた時に   フロントエンドのテストコードが   必要かもしれない  

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

フロントエンドテスト導入は「ストーリー」を意識しよう

フロントエンドテスト導入は「ストーリー」を意識しよう

ミカイ

More Decks by ミカイ

Featured

Transcript