CSS Layout Testing というテスト手法の提案

Web のフロントエンド実装において、次のようなミスによってデザイン崩れを起こしてしまったことはありませんか。

• flex-shrink の指定を忘れて、要素が押しつぶされてしまった
• z-index の指定を間違えて、要素が意図せず前面（または背面）に表示されてしまった
• object-fit の指定を間違えて、画像の一部が欠損してしまった

これらのデザイン崩れは、実装中に気づくこともあれば、リリース後に初めて気づいてしまうこともあります。
本記事では、このようなデザイン崩れについて、テストコードによって発生しないことを担保できないかと考え、その可能性を整理します。
なお、本記事にはサンプルコードは含まれていません。

デザイン崩れをチェックするアドオン

データ増減によるデザイン崩れを発見しやすくするため、私は次の Storybook アドオンを開発しました。

npmjs.com

このアドオンを使うことで、数値や配列などの Props に対して、スライダー UI を用いて簡単にデータを増減させることができます。
コンポーネントに対して、想定より多い・少ないデータを与えながら表示を確認できる点で、便利なツールです。

一方で、この確認作業は最終的に人の目によるチェックに依存しており、「デザインが崩れていないこと」を仕組みとして保証できているわけではありません。

CSS Layout Testing

こうしたデザイン崩れに対して、テストコードを書くことで問題を防げないかと考えました。
そこで、次のような方法で、レイアウトに関するテスト、CSS Layout Testing を構築できるのではないかと思います。

1. Vitest Browser Mode を利用し、Playwright 上でテストを書く
   • JSDOM のような仮想 DOM ではなく、実際のブラウザ上で動かすことが重要です
2. テストコード内で Web API を使い、レイアウトが崩れていないかを検証する
   • getBoundingClientRect: 要素の表示位置や横幅・縦幅を取得できる
   • elementFromPoint: 指定した位置において、最前面に描画されている要素を取得できる
   • そのほか、必要に応じた API

例えば、「flex-shrinkの指定を忘れて、要素が押しつぶされてしまった」というケースであれば、 対象となる要素の横幅や縦幅を getBoundingClientRect で取得し、一定以上のサイズを保っていることを検証する、といったテストが考えられます。

また、「z-indexの指定を間違えて、要素が意図せず前面（または背面）に表示されてしまった」というケースでは、該当箇所まで移動した上で、特定の X 軸・Y 軸に対してelementFromPoint を実行し、取得された要素が意図する要素であることを検証する、といったテストが書けそうです。

これらの問題は、CSS Lint の設定によって防げる場合もありますし、Visual Regression Testing（VRT）によって検出できる場合もあります。ただし、Lint ではすべてのデザイン崩れを拾えるわけではありませんし、VRT についても、画像ファイルの管理や実行時間の増加などの制約があります。

おわりに

サンプルコードを用意しようかと思ったのですが、都合により準備することができませんでした。時間があれば、試してみたいと思います。

シェアする

フォローする

関連する記事

タグ「フロントエンド」の記事

ヒューマンインターフェース ガイドライン という言葉を知りました。

最近、ヒューマンインターフェース ガイドライン（HIG）という言葉を知りました。 「ヒューマンインターフェイスガイドライン」には、どのAppleプラットフォームでも優れた体験を設計できるようにするためのガイドとベストプラクティスが含まれてい

2026-01-24

フロントエンド

AIの利用上限に達した時にすることを残しておく

主にWeb関連の個人開発をしている際に心がけていることを書きます。 月末に近づくにつれ、AIの利用上限に達してしまうことがあります。 その状況になった時、以下のいずれかの選択肢が私の中では残っています。 課金して利用上限を増やす 無料モデル

2026-01-22

フロントエンド

AI

CSSで頑張らなくても、SVGで楽にできるときもある

個人サイトをリニューアルをしています。 ノート風のデザインを目指して、スタイルを調整していました。 ノートの見た目は、現実にあるノートを再現しようとCSSを書いていました。 現在、以下の画像のようなノートになっています。 ノート風デザインの

2026-01-20

フロントエンド

タグ「テスト」の記事

単体テストを全通り書くんじゃない！

AIの進化によって、プロダクションコードに対するテストコードは、以前と比べて格段に書きやすくなったと感じています。 単体テストに関する基本的なお作法については、以前に以下の記事で整理しました。 興味があれば、参考として読んでもらえると嬉しい

2026-01-09

テスト

Playwright の POM を Storybook 上で確認してから E2E テストを書く

はじめに Playwright で E2E テストを書く際、playwright codegen や、近年では Playwright MCP を利用して、テストコードの雛形を作成することが多いと思います。 ただし、生成したテストコードが正し

2025-12-26

テスト

Storybook の Story を Vitest Browser Mode with Playwright で VRT

Storybook の Story オブジェクトを Vitest の Browser Mode だけで、Visual Regression Test（VRT）ができるようになりました。 本記事では、その導入手順をコンパクトに紹介します。 前

2025-12-03

フロントエンド

テスト

← ブログ一覧へ