Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Webフロントエンドのための実践「テスト」手法 CodeZine Night #1

Webフロントエンドのための実践「テスト」手法 CodeZine Night #1

CodeZine編集部主催のウェビナー「CodeZine Night」の第一回発表資料
https://codezine.connpass.com/event/279012

Takepepe

May 10, 2023
Tweet

More Decks by Takepepe

Other Decks in Programming

Transcript

  1. 第1章:フロントエンドテストを書く目的 ▪ Playwright も追従 ー v.1.27.0 で、Locator に新機能(書籍執筆中に発生) ー getByRole など、Testing Library にインスパイアされた

    API ー 公式として、この Locator を使用したコードを推奨 フロントエンドテストツールの変化 New APIs, inspired by Testing Library: https://github.com/microsoft/playwright/releases/tag/v1.27.0
  2. 第2章:a11y の当たり前品質 Full accessibility tree とは? ▪ Google Chrome の 実験的な機能

    ▪ Elements パネルから確認でき、日常のデバッグに便利 ▪ Storybook では、UI コンポーネント単位でツリーが確認できる Full accessibility tree in Chrome DevTools: https://developer.chrome.com/blog/full-accessibility-tree
  3. 第2章:a11y の当たり前品質 a11y 欠陥の具体例 axe-playwright を使用した、Story 毎のアクセシビリティ違反チェック ▪ 事例3:デザインを調整する例 await checkA11y(page,

    "#root", { includedImpacts: ["critical", "serious"], detailedReport: false, detailedReportOptions: { html: true }, axeOptions: storyContext.parameters?.a11y?.options, });
  4. 第2章:a11y の当たり前品質 a11y 欠陥の具体例 "critical", "serious", "moderate", "minor" の検証レベル指定(コントラスト比は "serious")

    ▪ 事例3:デザインを調整する例 await checkA11y(page, "#root", { includedImpacts: ["critical", "serious"], detailedReport: false, detailedReportOptions: { html: true }, axeOptions: storyContext.parameters?.a11y?.options, });
  5. 第2章:a11y の当たり前品質 a11y 欠陥の具体例 ▪ 事例4:E2E テストで見つかった a11y 欠陥 ー Storybook では

    a11y 違反は検出されなかった ー 自動テストが失敗。原因は何だったか? 参考PR:https://github.com/frontend-testing-book/nextjs/pull/6
  6. 第2章:a11y の当たり前品質 a11y 欠陥の具体例 a11y 欠陥は E2E テスト時に発覚することも ▪ 事例4:E2E テストで見つかった

    a11y 欠陥 test("アクセシビリティ検証 ", async ({ page }) => { await page.goto(url(path)); await injectAxe(page); await checkA11y(page); });
  7. 第2章:a11y の当たり前品質 axe について ▪ Web アクセシビリティのための自動テストツール ー ブラウザで利用する a11y 検証ツール(ブラウザ固有のテスト) ー Testing

    Library は DOM から算出した a11y tree 検証にとどまる ー Storybook test runner でしか検出できない欠陥 → コントラスト比等 ー ブラウザE2Eテストフレームワークでしか検出できない欠陥 ブラウザで実行されるため、忠実性の高い a11y 検証ができる
  8. 第2章:a11y の当たり前品質 a11y とテスト、どう向き合うか ▪ ARIA の誤用に気をつけよう ー テストのための符号として ARIA 属性を付与しがち ー テスト・デバッグツールの解釈と、支援技術には差がある

    ー テストついでに a11y 改善を行う場合、正しい用法か確認を ー テストで要素取得できているからといってアクセシブルとは限らない No ARIA is better than Bad ARIA:https://www.w3.org/WAI/ARIA/apg/practices/read-me-first
  9. 第2章:a11y の当たり前品質 a11y とテスト、どう向き合うか ▪ 自動テストを書く日常の一環として ー a11y の「当たり前品質」を担保するリグレッションテストとして ー できれば UI コンポーネント作成段階で

    a11y 品質を考慮しよう ー できれば支援技術(スクリーンリーダーなど)で確認を ー まず自動テストを書く事が目的なら、 data-testid 属性から始めて良い 自動テストで、アクセシビリティの「当たり前品質」を担保
  10. 第3章:テストがない状況からの脱却 テストツールの守備範囲 ▪ Story はテストケースとして import し、jsdom で検証できる composeStories は Storybook

    v7 に標準機能として統合 snapshot (DOM) 機能テスト VRT axe (a11y) E2E jsdom + RTL ✅ ✅ ❌ ❌ ❌ Storybook ✅ ✅ ✅ ✅ ❌ Playwright ❌ 🟠 🟠 🟠 🟠 import import
  11. 第3章:テストがない状況からの脱却 はじめの自動テストとして ▪  Storybook をお薦めする理由 ー  jsdom のテストケースとして Story を再利用

    (composeStories) ー VRT (ビジュアルリグレッションテスト) や axe (a11y ) も ー テスト対象が細分化されているめ、欠陥を突き止めやすい ー テストケースの状態 (UI) が目視で確認できる ー MSW も使える その時のニーズにあわせて取捨選択できる
  12. 第3章:テストがない状況からの脱却 MSW って何だっけ? ▪ Mock Service Worker ー モックサーバー(HTTP リクエストをインターセプトできる) ー UI コンポーネントに必要な、データ取得・更新

    API を再現 ー Jest だけでなく、Web API 依存の Story が表現できる ー 例えば 「Web API 取得失敗した場合表示はこうなる」という Story MSW Storybook Addon:https://storybook.js.org/addons/msw-storybook-addon
  13. 第3章:テストがない状況からの脱却 MSW って何だっけ? ▪ Mock Service Worker ー モックサーバー(HTTP リクエストをインターセプトできる) ー UI コンポーネントに必要な、データ取得・更新

    API を再現 ー Jest だけでなく、Web API 依存の Story が表現できる ー 例えば 「Web API 取得失敗した場合表示はこうなる」という Story MSW を使った技術記事をいくつか投稿しています :https://zenn.dev/takepepe
  14. 第3章:テストがない状況からの脱却 段階的に自動テストを導入しよう ▪ 自動テスト拡充のロードマップ(例) ー 1)ページ相当のコンポーネントを Story 登録 ー 2)MSW Storybook Addon を活用し、ページの

    Story を複数登録 ー 3)Storybook Play function を活用し、機能テストを追加する ー 4)Storybook Test runner が CI で実行されるよう設定 この段階で VRT(ビジュアルリグレッションテスト)があると尚良い