Slide 1

Slide 1 text

0 StorybookとPlaywrightではじめる インタラクションテスト 株式会社 enechain 中山晶平 (@nakker1218) E2Eテスト自動化の事例 4選 ~Playwight活用例~

Slide 2

Slide 2 text

1 ● 株式会社enechain ● 中山晶平 (Shohei Nakayama) ● @nakker1218 ● 札幌在住 󰪟 🏕 ● ソフトウェアエンジニア ○ Webアプリケーション ○ フロントエンド中心 E2Eテスト自動化の事例 4選 ~Playwright活用編~

Slide 3

Slide 3 text

2 E2Eテスト自動化の事例 4選 ~Playwright活用編~ ● Agenda ○ インタラクションテストを導入した課題感・背景 ○ なぜPlaywrightを選定したか ○ Playwright上でのインタラクションテストの実現 ○ 導入して

Slide 4

Slide 4 text

3 インタラクションテストを導入したプロダクト ● enechain ○ エネルギーのマーケットプレイスを運営 するスタートアップ ○ 電力, 燃料, 環境価値 ● eNgine ○ 取引を管理する社内システム ○ 複雑なドメインをカバー しながら、素早 く操作できる設計 ○ ミスが起こると事業に与える影響大 E2Eテスト自動化の事例 4選 ~Playwright活用編~

Slide 5

Slide 5 text

4 アプリケーションの特徴 ● 複雑なドメインをカバーするための細かい要件 ● ミスなく素早く操作するための高機能な操作性 ○ ポップアップウィンドウ , ショートカットキーなど ● これまでに発生したバグ ○ ポップアップウィンドウ上でのみ機能が動かない ○ 機能のショートカットキーが動かなくなっていた ○ 特定の要素が選択されているときに表示されるはずの フォームが表示されない E2Eテスト自動化の事例 4選 ~Playwright活用編~

Slide 6

Slide 6 text

5 すべての機能を手動テストで担保し続けることはコストが高い 󰗔 QAにかかる時間も増える 󰗔 リリース頻度の低下、価値提供の総量が減ることに繋がる

Slide 7

Slide 7 text

6 󰗔 自動テストで担保する範囲を広げることが重要

Slide 8

Slide 8 text

7 自動テストの戦略 ● ユーザーが業務で行う操作が問題なく動くことを保証する ○ コード自体には問題がなくても、業務上想定している挙動とは異なってしまうことがある ○ 一度決まって運用に乗った業務フローの変更頻度は、 コードの変更頻度よりも低い傾向にある ● 実際の操作に焦点を当てたテスト ● End to Endテスト ○ 実際のAPIに繋いでシステム全体のワークフローを検証する -> MagicPodを利用 ● インタラクションテスト ○ 各ユースケースの状態において期待通りに操作できるかを検証する -> Playwrightを利用 E2Eテスト自動化の事例 4選 ~Playwright活用編~

Slide 9

Slide 9 text

8 E2Eテスト自動化の事例 4選 ~Playwright活用編~ ● Agenda ○ インタラクションテストを導入した課題・背景 ○ なぜPlaywrightを選定したか ○ Playwright上でのインタラクションテストの実現 ○ 導入して

Slide 10

Slide 10 text

9 なぜPlaywrightを選定したか ● インタラクションテストの選択肢 ○ Storybook Test runner, Playwright, React Testing Libraryなど ● Playwrightを選んだ理由 ○ 実際のブラウザ上でテストができること ○ Storybookとの組み合わせでコンポーネントに対してテストができる ○ PlaywrightのVS Code Pluginが強力 ○ 社内の別プロダクトで導入事例があったこと E2Eテスト自動化の事例 4選 ~Playwright活用編~

Slide 11

Slide 11 text

10 なぜPlaywrightを選定したか ● 実際のブラウザ上でテストができること ○ 先の選択肢の中だと React Testing Library以外はあればブラウザ上での実行 ○ Storybook Test runnerは describe、test に相当するものがなく複雑なテストを書きにくかった ● Storybookとの組み合わせでコンポーネントに対してテストができる ○ Playwright Componentsも出てるがまだ experimental ● PlaywrightのVS Code Pluginが強力 ○ GUI上からコード生成や検証ができる ● 社内の別プロダクトで導入事例があったこと E2Eテスト自動化の事例 4選 ~Playwright活用編~

Slide 12

Slide 12 text

11 E2Eテスト自動化の事例 4選 ~Playwright活用編~ ● Agenda ○ インタラクションテストを導入した課題・背景 ○ なぜPlaywrightを選定したか ○ Playwright上でのインタラクションテストの実現 ○ 導入して

Slide 13

Slide 13 text

12 Storybookの整備 E2Eテスト自動化の事例 4選 ~Playwright活用編~

Slide 14

Slide 14 text

13 PlaywrightでStorybookを読み込む E2Eテスト自動化の事例 4選 ~Playwright活用編~

Slide 15

Slide 15 text

14 インタラクションテストの実装 E2Eテスト自動化の事例 4選 ~Playwright活用編~

Slide 16

Slide 16 text

15 CIで検証 ● GitHub Actions上でPR事に実行 E2Eテスト自動化の事例 4選 ~Playwright活用編~

Slide 17

Slide 17 text

16 E2Eテスト自動化の事例 4選 ~Playwright活用編~ ● Agenda ○ インタラクションテストを導入した課題・背景 ○ なぜPlaywrightを選定したか ○ Playwright上でのインタラクションテストの実現 ○ 導入して

Slide 18

Slide 18 text

17 導入して ● メリット ○ 人間による QAの工数を減らせた ○ デグレの早期発見ができた ○ VRT導入にもつながった ● デメリット ○ CIの実行時間が伸びた ○ モックデータの作成が大変 ○ テストを書く・更新するコストが高い E2Eテスト自動化の事例 4選 ~Playwright活用編~

Slide 19

Slide 19 text

18 CIの実行時間削減の工夫 ● PlaywrightのSharding機能を使ってテストの分割実行をする ○ 10分割しても全ケース実行に 5-8分程度かかっていた ● 変更に関係ないコンポーネントのテストを実行しないように ○ chromaticのTurboSnapを参考に ■ Gitの差分とコンポーネントの Dependency Graphをもとに 変更内容に関連したコンポーネントのみ snapshotを実行する機能 ○ gitの差分とvite-plugin-turbosnapを使って、 変更に関連したコンポーネントのテストを抽出する CLIを作成 󰗔 1-2分程度まで削減 E2Eテスト自動化の事例 4選 ~Playwright活用編~ https://www.chromatic.com/docs/turbosnap/ Before After

Slide 20

Slide 20 text

19 導入して ● メリット ○ 人間による QAの工数を減らせた ○ デグレの早期発見ができた ○ VRT導入にもつながった ● デメリット ○ CIの実行時間が伸びた ○ モックデータの作成が大変 ○ テストを書く・更新するコストが高い E2Eテスト自動化の事例 4選 ~Playwright活用編~

Slide 21

Slide 21 text

20 ● TechBlogで今回の取組みの詳細な説明 をしています! ● もっと詳しく話したい方 : ○ Xやカジュアル面談 でお話しましょう! ● フロントエンドエンジニア募集中です! E2Eテスト自動化の事例 4選 ~Playwright活用編~ 宣伝

Slide 22

Slide 22 text

21