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 についても、画像ファイルの管理や実行時間の増加などの制約があります。

おわりに

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

-

読者になる

|

シェアする

|

ブログを応援する

この記事がよかったら、お布施という形で応援してもらえるとうれしいです。

おふせぼたん

関連する記事

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

念の為に、手動確認をしよう

最近のお悩みは、Webのソフトウェア開発におけるテストコードが爆増したことにより、 テスト成功による過度な安心感 によって手動確認するのが減っているのかもと思ったりしています。 例えば、Webのフォーム画面に小さな改修があったとして、その修

2026年06月03日

AI

フロントエンド

モバイルアプリからPWAアプリへ切り替え

以下で書いた個人ブログを読むアプリ（個人ブログライブラリ、略して "こぶりー" ）をモバイルアプリで開発していました。 https://silverbirder.github.io/blog/contents/20260419/ 審査関連で

2026年05月11日

フロントエンド

モバイルアプリを作る機運が高まった

過去にモバイルアプリを作ろうとして断念したことがありました。 https://silverbirder.github.io/blog/contents/first-mobile-app-failure/ 最近、作りたいモバイルアプリのネタが

2026年04月14日

フロントエンド

タグ「テスト」の記事

テストコード、どこに何書く

業務でWebフロントエンドのテストコードを書く際に、どこに何を書くかというのをざっくりと考えをまとめてみます。 前提 Webアプリケーションのプログラムファイルがツリー構造である前提とします。 tree よくあるフィーチャー単位のフォルダ構

2026年06月05日

テスト

テストコードの意味がない

個人開発のバイブコーディングでテストコードを書かせているが意味がなかった。 期待する機能をプロンプトで指示しプロダクションコードが出来上がるが、同時にテストコードも書かせていた。 そのテストコードは、プロダクションコードをそのままテストコー

2026年05月31日

AI

テスト

Testcontainers 導入の苦労話メモ

最近、Testcontainers を使う機会があり、苦労したことについて備忘録として残しておきます。 前提 以下の記事で書いてある構成に近いものです。 https://zenn.dev/silverbirder/articles/0a54

2026年05月14日

テスト

← ブログ一覧へ