なぜ「インライン要素のテスト」が疎かになるのか？ Jestとjsdomで足元を固める
フロントエンド開発の現場で、コンポーネントテストを書くとき、私たちはついつい「巨大なUIパーツ」や「複雑なロジック」にばかり目を奪われがちです。しかし、アクセシビリティやSEO、そして意図したデザインを担保するのは、往々にして`span`や`strong`、`time`といった「地味なインライン要素」の正確なレンダリングです。
「単なるテキストタグの検証なんて、スナップショットテストで十分じゃないか？」
そう思う方もいるかもしれません。しかし、スナップショットテストは「変わったこと」を教えてくれるだけで、「なぜそれが正しいのか」という意図までは保証してくれないのです。本稿では、Jestとjsdomを使い、インライン要素を型通りに、かつ堅牢にテストするためのプラクティスを共有します。
—
1. ブラウザの裏側：インライン要素の「素顔」を理解する
まず前提として、ブラウザは`span`や`strong`を単なる文字の塊として扱っているわけではありません。
- `span`: 意味を持たないプレーンなコンテナ。CSSのフックや、一部のテキストだけスタイルを当てるために使われます。
- `strong` / `em`: これらは「重要性」や「強調」というセマンティクス（意味論）を持ちます。スクリーンリーダーはこれらを単なるスタイルとしてではなく、読み上げのアクセントとして解釈します。
- `time`: マシンリーダブルな日付データ。機械的に解釈可能な`datetime`属性を持つことで、検索エンジンやカレンダーアプリに正確な時間を伝えます。
jsdomは、ブラウザのDOMツリーをJavaScriptオブジェクトとしてエミュレートする環境です。ここでのテストは、実機ブラウザのレンダリングエンジンを完全再現するものではありませんが、「DOMツリー上の構造と属性が、意図した通りに生成されているか」を確認するには十分すぎるほど強力なツールです。
—
2. 実践：インライン要素のテスト実装パターン
実務でよくある「日付フォーマット付きの強調表示」を例に、テストコードを書いてみましょう。ただ要素があるか確認するのではなく、「セマンティクスと属性が正しいか」をテストの焦点にします。
/
- テスト対象のコンポーネント（イメージ）
- 2023年10月27日
/
import { render, screen } from ‘@testing-library/react’;
import ‘@testing-library/jest-dom’; // これを忘れずにインポート！
describe(‘DateTimeDisplay コンポーネントのテスト’, () => {
test(‘正しいセマンティクスと属性を持ってレンダリングされること’, () => {
render(
// 1. timeタグを取得し、datetime属性が正しいか検証
const timeElement = screen.getByText(/2023年10月27日/i).closest(‘time’);
expect(timeElement).toBeInTheDocument();
expect(timeElement).toHaveAttribute(‘datetime’, ‘2023-10-27’);
// 2. strongタグが存在し、期待するクラスを持っているか検証
const strongElement = screen.getByText(/2023年10月27日/i);
expect(strongElement.tagName).toBe(‘STRONG’);
expect(strongElement).toHaveClass(‘highlight’);
});
});
このコードのポイント
- `closest(‘time’)`の活用: 階層構造を意識したセレクションです。特定のテキストがどの要素に包まれているかを検証することで、マークアップの誤りを防ぎます。
- `toHaveAttribute`: これが重要です。特に`time`タグの`datetime`属性は、SEOやアクセシビリティの要。ここをテストコードで固めておけば、将来的なリファクタリングで「うっかり属性を消してしまった」という事故を防げます。
- `tagName`による型チェック: Jestの`toBeInTheDocument()`だけでなく、具体的なタグ名までチェックすることで、後から誰かが`span`に書き換えたような場合にテストが即座に失敗するようにしています。
—
3. なぜ「インライン要素」のテストを丁寧に行うのか
大規模開発において、DOM構造の崩れは「小さな綻び」として放置されがちです。しかし、インライン要素への配慮不足は、以下のような負債を生みます。
1. アクセシビリティの低下: `strong`であるべき場所が`span`で表現されていると、スクリーンリーダー利用者はその情報の重要性に気づけません。
2. 保守性の低下: CSSクラスを`span`にベタ打ちしている場合、クラス名の変更がHTML構造の破壊に直結します。
3. データ品質の低下: `time`タグの`datetime`属性が空であれば、構造化データとしての価値がゼロになります。
まとめ：泥臭いテストこそ、フロントエンドの矜持
テストコードを書くことは、単なる自動化ではありません。「このHTML構造にはこういう意図がある」というドキュメントを、動くコードとして残す作業です。
今回紹介した`jest-dom`の matcher（`toHaveAttribute`, `toHaveClass`, `toBeInTheDocument`）を適切に組み合わせるだけで、あなたのコンポーネントは格段に堅牢になります。
「たかがspan、されどspan」。フロントエンドのシニアとして、こうした細部へのこだわりを忘れないエンジニアでありたいものです。さあ、今すぐプロジェクト内のインライン要素を、テストで守りに行きましょう。
コメント