## デザインシステムテストのギャップデザインシステムには200以上のコンポーネントストーリーを持つStorybookがあります。すべてのコンポーネントにはpropsと動作のユニットテストがあります。しかし、`variant="destructive"`と`size="sm"`を持つ`Button`コンポーネントが正しい赤い背景と32pxの高さでレンダリングされることを実際に検証している人はいますか？これがビジュアルテストが埋めるギャップです。すべてのコンポーネントの、すべてのバリアントの、すべてのブレークポイントでのビジュアル出力を検証します。 ## テストマトリクス典型的なデザインシステムのボタンコンポーネントのテストマトリクスは以下のようになります： | 次元 | 値 | |-----------|--------| | バリアント | default, secondary, destructive, outline, ghost, link | | サイズ | sm, md, lg | | 状態 | default, hover, focus, disabled, loading | | コンテンツ | テキスト, アイコン, テキスト+アイコン | | テーマ | ライト, ダーク | つまり 6 × 3 × 5 × 3 × 2 = **540のビジュアル状態**が単一のコンポーネントに存在します。システム内の数十のコンポーネントを掛けると、手動ビジュアルQAが不可能な理由がすぐに理解できます。 ## Storybookとの自動化 Storybookはデザインシステムのビジュアルテストの自然な統合ポイントです。各ストーリーがビジュアル状態を表します： ```tsx // Button.stories.tsx export const AllVariants: Story = { render: () => (

{(['default', 'secondary', 'destructive', 'outline'] as const).map( (variant) => (

) )}

), } ``` 次に、ビジュアルテストツールを使って、すべてのPRですべてのストーリーのスクリーンショットをキャプチャして比較します。 ## テーマバリアントの処理デザインシステムは通常、ライトテーマとダークテーマをサポートします。ビジュアルテストは両方をカバーする必要があります： ```typescript const themes = ['light', 'dark'] as const for (const theme of themes) { test(`button renders in ${theme} mode`, async ({ page }) => { await page.goto(`/iframe.html?id=button--all-variants`) await page.evaluate((t) => { document.documentElement.classList.toggle('dark', t === 'dark') }, theme) await expect(page).toHaveScreenshot(`button-${theme}.png`) }) } ``` ## トークンの検証ビジュアル比較の先に、コンポーネントが正しいデザイントークンを使用しているかを検証できます： ```typescript test('button uses correct design tokens', async ({ page }) => { await page.goto('/iframe.html?id=button--default') const button = page.locator('button') const styles = await button.evaluate((el) => { const computed = getComputedStyle(el) return { backgroundColor: computed.backgroundColor, borderRadius: computed.borderRadius, fontWeight: computed.fontWeight, padding: computed.padding, } }) expect(styles.borderRadius).toBe('8px') expect(styles.fontWeight).toBe('500') }) ``` これにより、ビジュアルレベルだけでなくトークンレベルでCSSドリフトをキャッチできます。 ## レスポンシブコンポーネントテストコンポーネントはすべてのビューポートサイズで動作する必要があります。モバイルで水平から垂直レイアウトに切り替わるカードコンポーネントの場合： ```typescript test('card switches layout at mobile', async ({ page }) => { // デスクトップ - 水平レイアウト await page.setViewportSize({ width: 1024, height: 768 }) await page.goto('/iframe.html?id=card--responsive') await expect(page.locator('.card')).toHaveScreenshot('card-desktop.png') // モバイル - 垂直レイアウト await page.setViewportSize({ width: 375, height: 812 }) await expect(page.locator('.card')).toHaveScreenshot('card-mobile.png') }) ``` ## 承認ワークフロービジュアルテストが変更を検出したとき、その変更が意図的かどうかを誰かが判断する必要があります。デザインシステムでは、このワークフローに以下を含めるべきです： 1. **エンジニアリングレビュー** — コードの正確性 2. **デザインレビュー** — 見た目の正確性 3. **自動チェック** — アクセシビリティ（コントラスト比、テキストサイズ） ChromaticのようなツールはこのワークフローをPRプロセスに直接統合し、ワンクリック承認でサイドバイサイドの比較を表示します。 ## カバレッジの測定どのコンポーネントにビジュアルテストがあり、どのコンポーネントにないかを追跡します： ```bash # ストーリーとビジュアルテストカバレッジを比較 total_stories=$(find src -name "*.stories.tsx" | wc -l) tested_stories=$(grep -rl "toHaveScreenshot" tests/ | wc -l) echo "Visual test coverage: $tested_stories/$total_stories" ``` コアコンポーネント（ボタン、インプット、カード、ナビゲーション）は100%のカバレッジを、複合コンポーネントは少なくとも80%のカバレッジを目指しましょう。 ## ScanUで始めるこれらのテクニックを本番環境で適用するには、注力するページセットから始めて、意味のあるUI変更のたびにベースラインスクリーンショット比較を実行しましょう。プランは[料金](/pricing)、実装の詳細は[FAQ](/faq)、プロダクトの機能は[機能](/features)で確認できます。

インサイト ＆エンジニアリング

インサイト＆エンジニアリング