ホーム自己紹介ブログ
NO.223
DATE2026. 01. 10

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

おわりに

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

フロントエンド
テスト

-

読者になる

|

シェアする

|

silverbirders

silverbirder

Webソフトウェアエンジニア

ブログを応援する

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

おふせぼたん

※ ログイン不要で投稿できます。

※ 同じブラウザから投稿を削除できます。

0

読み込み中...

次の記事へ前の記事へ

関連する記事

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

Webフロントエンドのコードレビューメモ2

また、以下の記事の続きを書こうと思います。 https://silverbirder.github.io/blog/contents/20260312/ ビジネスロジック アプリケーションのビジネスロジックに関することについて書きます。 複

2026年03月18日

フロントエンド
Webフロントエンドのコードレビューメモ

Webフロントエンドのコードレビューをしているときに考えていることについて書きます。 毎日1記事投稿、1記事30分という制約を課していますので、本記事は完璧ではありません。(言い訳) また希望的な考えもあるので、実践していないものもあります

2026年03月12日

フロントエンド
AIの書いたコードの手直しを減らすお作法

AI にコードを書かせた後、余計なコードを見つけて消す作業があります。 不毛なことなので、それらの作業を減らすためのお作法を紹介します。 未使用コードを消す 以下でも書きましたが、未使用コードの検査に knip を使うことが多いです。 ht

2026年02月25日

AI
フロントエンド

タグ「テスト」の記事

CSSを、Vitestでテストしてみる

以下の記事で書いた CSSをテストする方法について、試してみました。 https://zenn.dev/silverbirder/articles/df6752b230f04c ソースコードは、以下に置いています。 https://gith

2026年02月10日

フロントエンド
テスト
単体テストを全通り書くんじゃない！

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

2026年01月09日

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

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

2025年12月26日

テスト
← ブログ一覧へ