PlaywrightとStorybookの連携試行記

ツール導入前の課題

手動によるUI確認の工数

初期開発から数年が経過し、ライブラリのアップデートを実施したいという意向はあったものの、フロントエンド開発者が2名という限られたリソースの中でプロダクト開発を継続していたため、アップデートに踏み切る余裕がありませんでした。

変更による予期せぬ影響

Storybook を利用していたにも関わらず、ビジュアルの変化を自動で検知する仕組みが不足していたため、細かな差分に気づきにくいという課題を抱えていました。

どのような状態を目指していたか

予期せぬ変更影響の把握

手動レビューでは見逃しがちな細かなUI変更を自動的に検出し、UIライブラリのアップデートに伴うリスクを低減することを目指しました。

効率的な開発体制の構築（VRTの自動化）

限られた開発者数でも安心してUIライブラリの更新を進められるよう、迅速なフィードバックループの確立によって、開発効率を向上させることを狙っています。

VRT（Visual Regression Testing）とは
VRTとは、アプリケーションのユーザーインターフェース（UI）の見た目を定期的に記録し、後の変更と比較することで、意図しないビジュアル上の差分や不具合を自動的に検出するテスト手法です。デザインやレイアウトの微妙な変化も見逃さず、手動による確認工数を大幅に削減し、品質保証の効率化を目指しました。

Storybookとの統合

Storybookとの統合により、コンポーネント単位でのテストが容易になり、既存の開発フローに自動テストを自然に組み込むことを目指しました。

低コストかつ柔軟な試行

フロントエンドエンジニアが少人数であるため、プロダクト開発と並行して実施する必要があり、導入コストを最小限に抑えることが重要でした。

学習コストを抑える

プロダクト開発と並行して進めるため、導入によって追加の工数が発生しないことが求められました。具体的には、情報過多にならず、複数のツールを組み合わせる必要がないシンプルな構成であることを目指しました。

Playwright+StoryBookでVRTが行える

Playwright単体でスクリーンショットの取得、比較、UI上での差分確認が可能なため、追加のライブラリを導入することなく試行できる点が魅力的でした。

Playwrightの拡張性

初回の導入目的はVRTの実施でしたが、E2Eテストツールとしても優秀なPlaywrightの拡張性が魅力的でした。

PlaywrightはStorybook専用のVRTツールではないため、あらかじめStorybookを立ち上げ、そのStorybookに対してスクリーンショットを取得する必要がありました。この一連の流れを構築するには、例えばStoryCapなどのSaaSツールと比較すると、構築に時間がかかるという課題がありました。

CI/CDへの統合検討

将来的には、CI/CDパイプラインへの統合を目指す予定ですが、OS依存による差分問題の解決が前提となります。現状では、各開発者がローカル環境でテストを実行し、push直前に差分を確認する形で運用しています。

本運用への移行

今回の試行はあくまで初期段階であり、本格的な運用効果についてはまだ判断できません。今後は、テストケースの充実とStorybook上のコンポーネント網羅性の向上を図りながら、本運用を目指していきます。