Playwrightを導入して安心安全にリファクタリングに取り組む

ツール導入前の課題

カミナシでは、フロントエンド領域において2つの課題を抱えていました。

1. プロダクションコードの内部品質が低い

一部の画面では、以下のような技術的課題があり内部品質が低い状態でした。

• ロジックが様々な箇所に散らばって存在（hooks、component、reducer、saga各層に分散）
• 多段のuseEffectによる処理の連鎖で、コード上から処理を追うことが困難
• TypeScriptの型エラーが放置状態

2. 画面全体の機能を網羅するテストの不足

既存のユニットテストは複雑な計算処理などの関数に対してのみ実施されており、画面全体の機能を包括的にテストできていませんでした。その結果、リリース後にリグレッションやバグが発生し、ロールバックが必要となることが頻繁に発生していました。

1の問題を解決するためにリファクタリングを実施したい思いはありましたが、テストが不足しているなかでの改善はリグレッションのリスクがあるため、必要なリファクタリングに踏み切れない状況が続いていました。

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

我々が目指していたのは、「大規模なコード変更においても動作を保証できる」ブラウザテストでした。

具体的には下記のようなイメージです。

1. リファクタリング時の動作保証ができる包括的なテストの実現
2. 開発者が自信を持ってコード変更できる環境の構築
3. バグやリグレッションの早期発見体制の確立

• React Testing Library (RTL)
• Playwright

1. 画面を見ながらテストの作成・デバッグができるか
2. 大規模な変更でも動作を保証できるか
3. テストコードの維持・更新がしやすいか
4. VRTなど既存の仕組みとの連携が可能か

1. 優れた開発体験

RTLでのブラウザテスト作成時に経験した「画面が見えない状態でのテスト作成の辛さ」を解決できることが大きな魅力でした。Playwright Inspector による要素取得コードの自動生成機能により、テスト作成・保守の効率が大幅に向上することが期待できました。

2. 既存環境との親和性

すでにVisual Regression Testで部分的にPlaywrightを導入していたため、追加の学習コストや環境構築コストが最小限で済むことが分かりました。

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

リファクタリングを実施する際、テストが通っている限り、機能が正常に動作することに確信を持てるようになりました。

リリース後のロールバック頻度も減少しました。

どのような成果が得られたか

内部品質向上のためのリファクタリングを実施できるようになりました。

また、Dependabot による継続的なライブラリアップデート運用が可能になりました。

アクセシビリティ対応が十分でないコンポーネントが多く、適切なセレクタの選定に苦労しました。data-testidを全要素に振ると保守性が下がるため、必要最小限に留めつつ、可能な限りaria-labelなどのアクセシビリティ属性を活用する方針を採用しました。

Page Object Modelの導入により、要素の特定や操作をページ単位で抽象化しましたが、適切な粒度での抽象化に試行錯誤が必要でした。

また、Safari環境でのテスト実行に15分程度かかっており、開発体験を損ねる要因となっていました。

段階的導入

いきなり全画面をテスト対象にするのではなく、重要度の高い画面から段階的に導入することで、コスパ良く効果が得られます。

Page Object Model(POM) は使わなくてよいかもしれない

PlaywrightはSeleniumなど過去のテストツールと違って基本的にauto-retryなどいい感じに待ったり再リトライしてくれます。 また、a11y要素など要素の取得方法がロバストであればPOMを使わなくても充分安定したテストを記述することが可能です。

適切な粒度での抽象化は難易度高く試行錯誤が必要になるため、セレクターをベタ書きする方が無難かもしれません。

CI最適化は継続的に行う

テスト数が増えるにつれてCI時間が長くなるため、キャッシュ活用やlarge runnerの部分的利用など、継続的な最適化が重要です。

現在未対応の画面への展開を広げつつ、CI実行時間が悪化しないよう最適化も合わせて進めていきたいと考えています。