CSSを1行変えただけなのに、まったく別のページのボタンが静かに崩れている。テストは何も落ちず、レビューでも気づかれず、1週間後にユーザーからの報告で発覚する。小さなチームなら、誰でも覚えのあるバグだと思います。
教科書的な答えは「ユニットテストを増やしましょう」です。私も少人数の開発チームを見ていますが、正直なところ、すべてのコンポーネントとレイアウト状態にユニットテストを書く余裕はありません。代わりに頼っているのがビジュアルテストです。ページのスクリーンショットを撮り、正常時のベースラインと比較して、動くはずのないピクセルが動いたらビルドで知らせる。かかる手間を考えると、これに匹敵する方法を他に知りません。
スクリーンショットが働き者である理由#
魅力は「書かなくていいもの」の多さです。ビジュアルテストは個々の要素にアサーションを書くのではなく、ページ全体をまとめて判定します。レイアウトのずれ、色の変化、レスポンシブの崩れ、要素の重なり。コードレビューをすり抜けやすく、ユニットテストでカバーしようとすると苦行になるものばかりですが、これらが全部PR上の差分として現れます。
メンテナンスもほぼゼロです。ベースラインを一度設定すれば、あとはPRごとに自動で実行され、毎回同じ結果が返ってきます。意図したUI変更ならベースラインを更新して次へ。意図していない変更なら差分がPRに出ているので、サイトの半分をクリックして回って探す必要はありません。
ユニットテストの代わりにはなりません#
ユニットテストはロジックを、スクリーンショットは見た目を検証します。最終的には両方欲しいところです。ただ、小さなチームで最初の数時間をどこに使うか選ぶなら、セットアップ時間あたりのカバレッジはビジュアルテストが一番だと思います。私の目安は、壊れると本当に痛いビジネスロジックにはユニットテスト、それ以外はビジュアルテスト、です。
仕組みはこれで全部です。ベースラインと、PRごとの差分と、たまに「はい、これは意図的な変更です」とクリックするだけ。それにしては、よく働いてくれます。
詳細情報と参考リンク#
Visual Testing with Playwright#
Playwrightのスナップショットテストのドキュメント。ページ全体や特定要素をキャプチャしてベースラインと比較する方法と、意図的なUI変更時のベースライン更新の方法がまとまっています。 Visual Testing with Playwright
Best Practices for Testing with Playwright#
データベースを扱うテストのためのPlaywrightの推奨事項。テストデータの分離、テスト後のクリーンアップ、テストの独立性の保ち方が解説されています。 Best Practices for Testing with Playwright