０からのPlaywright導入とその成果

ツール導入前の課題

全体的にUIを刷新したタイミングで、自動遷移などの機能が増え、フロントエンドの複雑性が高まりました。さらに、古いUIと新しいUIを工場ごとに出し分けていたため、両方のUIの動作確認を行う必要がありました。 その結果、不具合の見落としが発生しやすくなっていました。

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

• ユーザーにとって重要な部分は自動でテストができ、不具合の見落としてを防いで安心して機能の追加などができること。
• また、ビジュアルリグレッションテストを導入して、UIのデグレを防ぐこと。

Cypress

• ツールの便利さ
• 信頼性
• 導入のしやすさ

Cypressとどちらを使用するか悩みましたが、テストの並列実行が可能だったりビジュアルリグレッションテストも簡単に導入できたりと、機能的にPlaywrightの方が便利な点がいくつかありました。

また、導入の2024年当時にPlaywrightの方がダウンロード数の面でも勢いがあったのでPlaywrightを選択しました。

テストもTesting Libraryと同じような文法なので、学習コストが低そうだったのも要因の一つです。

改善したかった課題はどれくらい解決されたか

かなり解決したと感じています。

現在はポストモーテムを実施していますが、テスト導入前は特にそのような定期的な障害の振り返りを行っておらず、厳密な比較はできないですが、体感や最近のポストモーテムの内容的にテスト導入前に比べてフロントエンドにおけるクリティカルな障害はかなり減ったかなと思います。

最初はテストケースの漏れなどで不具合が発生することがありましたが、その度に足りてなかったテストケースを追加することで不具合の発生をさらに減らすことができました。

現在はE2Eテストが通る = クリティカルな不具合は無いという状態にできているので、安心して機能追加などができています。

• 0からのE2Eテストの導入だったので工数が少しかかってしまった
• 最初はビジュアルリグレッションテストを実施していましたが、プロダクトのUI変更が多くメンテナンスが大変になり、費用対効果を考えて実施しなくなりました

上記で挙げたツールのメリットからE2Eテストの選定で悩んでいるのであれば、特別なユースケースがない場合は、Playwrightを選択しておけば問題ないと思います。

他にもフロントエンドのテスト導入で迷っていることがあれば、こちらの記事を参考にしてください。