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

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

View Slide

自己紹介
■　Takepepe（吉井健文）
■　社内横断開発組織に所属
■　フロントエンド開発の横断サポート

View Slide

【投票】「フロントエンド開発のためのテスト入門」は、もう読まれましたか？
フロントエンド開発のためのテスト入門
■　2023.4/24 翔泳社より刊行
■　フロントエンド開発におけるテスト手法を紹介
■　単体テストからE2Eテストまでを体系的に
■　自動テストがはじめてという方にも

View Slide

Agenda
■　第１章：フロントエンドテストを書く目的
■　第２章：a11y の当たり前品質
■　第３章：テストがない状況からの脱却
本日は、書籍で紹介しきれなかった内容が中心です

View Slide

第１章
フロントエンドテストを書く目的

View Slide

第１章：フロントエンドテストを書く目的
テスト、書いていますか？
【投票】フロントエンドの自動テストを導入して「良かった」と思ったことはありますか？
■　なんとなく今後の運用が「不安」である
■　バックログに積みっぱなしの「テストを書く」というチケット
■　いつまでたっても優先度があがらない

View Slide

テストの目的は何か？
■　目的はサービスの「品質」を保ち続けること
■　自動テストは「品質」を担保してくれる
■　自動テストを書くことで「品質」があがる
そもそも期待している「品質」って何だっけ？

View Slide

テストに求める「品質」の定義
■　狩野モデルによると、品質は5つに分類される
当たり前品質支障なくサービスが利用できること
一元的品質充足するとプラス評価、不充足はマイナス評価となるもの
魅力的品質競合にない付加価値で、プラス評価となるもの
無関心品質顧客の評価に影響しない、サービス提供側都合の品質
逆品質存在することで、サービスのマイナス評価となるもの

View Slide

テストに求める「品質」の定義
■　フロントエンド開発対象「UI」に置き換えると…
当たり前品質ボタンが押せて、画面遷移できる（欠陥がない）
一元的品質画面がサクサク遷移し、レスポンスが良い（非機能面が優良）
魅力的品質競合にない UI で、作業効率化のために欠かせない（差別化）
無関心品質顧客の評価に影響しない、サービス提供側都合の品質
逆品質存在することで、サービスのマイナス評価となるもの

View Slide

フロントエンド開発の自動テストスコープ
■　機能テスト（リグレッションテスト）
日常的な開発で、故障に気づけるように
当たり前品質一元的品質魅力的品質
利用者 ✅ ーー
？？？ーーー

View Slide

■　非機能テスト（パフォーマンステスト・アクセシビリティテスト等）
非機能要件追求は「コストと相談のうえ」という実態
利用者 ✅ ✅ ー
？？？ーーー

View Slide

■　Web アクセシビリティに対する関心の高まり
支援技術利用者目線でも、品質を向上しよう
利用者 (障害無し) ✅ ✅ ー
利用者 (障害有り) ❌ ❌ ー

View Slide

■　Web アクセシビリティに対する関心の高まり
【投票】普段 Web アクセシビリティを考慮できていますか？

View Slide

■　フロントエンドテストツールでいま
注力されているもの
Web アクセシビリティにも「当たり前品質」を

View Slide

■　Testing Library の狙い
ー　アクセシビリティ由来のクエリー（セマンティッククエリー）
ー　機能テストを書くと、a11y の「当たり前品質」を意識することに
ー　a11y の欠陥に、日常的に気づける
フロントエンドテストツールの変化
Queries Accessible to Everyone： https://testing-library.com/docs/queries/about#priority

View Slide

■　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

View Slide

第２章
a11y の当たり前品質

View Slide

第２章：a11y の当たり前品質
a11y の「当たり前品質」とは？
■　リンクを押下すると画面遷移できるか
■　フォームが送信できるか
■　ドキュメントが意図どおり提供できているか
ー　文章構造、CSS、a11y tree

View Slide

a11y tree とは？
■　アクションを実行できるアクセシビリティオブジェクトのツリー
■　DOMツリーから派生したもの
■　支援技術が属性とプロパティを照会
■　支援技術にドキュメントがどう見えているか示すツリー

View Slide

Full accessibility tree とは？
■　Google Chrome の実験的な機能
■　Elements パネルから確認でき、日常のデバッグに便利
■　Storybook では、UI コンポーネント単位でツリーが確認できる
Full accessibility tree in Chrome DevTools： https://developer.chrome.com/blog/full-accessibility-tree

View Slide


View Slide

a11y 欠陥の具体例
■　事例１：リンクにクリックログを仕込む
ー　onClick イベントにログ送信処理を追加
ー　画面遷移前にログを送信できている
ー　画面遷移もきちんと出来ている
ー　自動テストが失敗。原因は何だったか？
参考PR：https://github.com/frontend-testing-book/unittest/pull/5

View Slide

■　事例１：リンクにクリックログを仕込む
ー　onClick イベントにログ送信処理を追加
ー　画面遷移前にログを送信できている
ー　画面遷移もきちんと出来ている
href 属性がなくなった影響で「 link」ロールが欠落 → 支援技術利用者は画面遷移できない

View Slide

■　事例２：独自デザインのチェックボックスを実装する
ー　チェックボックスコンポーネントに状態を保持
ー　状態に応じてデザインを切り替えて
ー　チェックができ、状態が参照できている
参考PR：https://github.com/frontend-testing-book/unittest/pull/3

View Slide

　display: none; 指定による a11y tree からの除外 → 支援技術利用者は操作継続できない

View Slide

a11y tree の算出は CSS も関係する → jsdom のテストでは不十分な場合がある

View Slide

jsdom のテストでは不十分な場合 → CSS Modules をモックしている場合など

View Slide

■　事例３：デザインを調整する例
ー　デザインシステムを導入した
ー　デザイントークンを使用し、見出しに統一をもたせた
ー　デザインデータ通りの実装になった
参考PR：https://github.com/frontend-testing-book/nextjs/pull/5

View Slide

ー　デザインシステムを導入した
ー　デザイントークンを使用し、見出しに統一をもたせた
ー　デザインデータ通りの実装になった
コントラスト比が不十分 → 色覚障害のある利用者に見えない

View Slide

axe-playwright を使用した、Story 毎のアクセシビリティ違反チェック
await checkA11y(page, "#root", {
includedImpacts: ["critical", "serious"],
detailedReport: false,
detailedReportOptions: { html: true },
axeOptions: storyContext.parameters?.a11y?.options,
});

View Slide

"critical", "serious", "moderate", "minor" の検証レベル指定（コントラスト比は "serious"）
await checkA11y(page, "#root", {
includedImpacts: ["critical", "serious"],
detailedReport: false,
detailedReportOptions: { html: true },
axeOptions: storyContext.parameters?.a11y?.options,
});

View Slide

■　事例４：E2E テストで見つかった a11y 欠陥
ー　Storybook では a11y 違反は検出されなかった
参考PR：https://github.com/frontend-testing-book/nextjs/pull/6

View Slide

axe-playwright を使用した、ページ毎のアクセシビリティ違反チェック
test("アクセシビリティ検証 ", async ({ page }) => {
await page.goto(url(path));
await injectAxe(page);
await checkA11y(page);
});

View Slide

a11y 欠陥は E2E テスト時に発覚することも
test("アクセシビリティ検証 ", async ({ page }) => {
await page.goto(url(path));
await injectAxe(page);
await checkA11y(page);
});

View Slide

axe について
■　Web アクセシビリティのための自動テストツール
ー　ブラウザで利用する a11y 検証ツール（ブラウザ固有のテスト）
ー　Testing Library は DOM から算出した a11y tree 検証にとどまる
ー　Storybook test runner でしか検出できない欠陥 → コントラスト比等
ー　ブラウザE2Eテストフレームワークでしか検出できない欠陥
ブラウザで実行されるため、忠実性の高い a11y 検証ができる

View Slide

a11y とテスト、どう向き合うか
■　ARIA の誤用に気をつけよう
ー　テストのための符号として ARIA 属性を付与しがち
ー　テスト・デバッグツールの解釈と、支援技術には差がある
ー　テストついでに a11y 改善を行う場合、正しい用法か確認を
ー　テストで要素取得できているからといってアクセシブルとは限らない
No ARIA is better than Bad ARIA：https://www.w3.org/WAI/ARIA/apg/practices/read-me-first

View Slide

a11y とテスト、どう向き合うか
■　自動テストを書く日常の一環として
ー　a11y の「当たり前品質」を担保するリグレッションテストとして
ー　できれば UI コンポーネント作成段階で a11y 品質を考慮しよう
ー　できれば支援技術（スクリーンリーダーなど）で確認を
ー　まず自動テストを書く事が目的なら、
data-testid 属性から始めて良い
自動テストで、アクセシビリティの「当たり前品質」を担保

View Slide

第３章
テストがない状況からの脱却

View Slide

第３章：テストがない状況からの脱却
フロントエンド品質に a11y が関連するのは理解したけれど…
■　フロントエンドテストを書く動機
ー　リファクタリングしたいけれど、大丈夫
…？
ー　ライブラリをアップデートしたいけれど、大丈夫
…？
ー　新機能の追加、既存機能に影響でていない
…？

View Slide

フロントエンド品質に a11y が関連するのは理解したけれど…
■　フロントエンドテストを書く動機
ー　a11y 考慮が十分じゃないとテストは書けない？ → No
ー　最低限の「当たり前品質」を担保することが目的
気負わず出来るところから着手しよう

View Slide

フロントエンドテストを導入したいけれど…
■　現場に障壁があって…
ー　運用コスト・学習コストが高い
ー　テストを書く時間がない
ー　テストを書く文化がない
【投票】自動テスト導入の一番の障壁は何ですか？

View Slide

テストがない状況における目的
■　最低限の「当たり前品質」担保
利用者 (障害無し) ❌ ーー
利用者 (障害有り) ーーー
これを最短距離で達成するテストは何か？

View Slide

テストツールの守備範囲
■　テストツールには得意・不得意がある
✅：優良（詳細・速い）／　 🟠：守備範囲　／　❌：守備範囲外
snapshot (DOM) 機能テスト VRT axe (a11y) E2E
jsdom + RTL ✅ ✅ ❌ ❌ ❌
Storybook 🟠 🟠 ✅ ✅ ❌
Playwright ❌ 🟠 🟠 🟠 🟠

View Slide

テストツールの守備範囲
■　Story はテストケースとして import し、jsdom で検証できる
composeStories は Storybook v7 に標準機能として統合
snapshot (DOM) 機能テスト VRT axe (a11y) E2E
jsdom + RTL ✅ ✅ ❌ ❌ ❌
Storybook ✅ ✅ ✅ ✅ ❌
Playwright ❌ 🟠 🟠 🟠 🟠
import import

View Slide

はじめの自動テストとして
■　 Storybook をお薦めする理由
ー　 jsdom のテストケースとして Story を再利用 (composeStories)
ー　VRT (ビジュアルリグレッションテスト) や axe (a11y ) も
ー　テスト対象が細分化されているめ、欠陥を突き止めやすい
ー　テストケースの状態 (UI) が目視で確認できる
ー　MSW も使える
その時のニーズにあわせて取捨選択できる

View Slide

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

View Slide

MSW って何だっけ？
■　Mock Service Worker
ー　モックサーバー（HTTP リクエストをインターセプトできる）
ー　UI コンポーネントに必要な、データ取得・更新 API を再現
ー　Jest だけでなく、Web API 依存の Story が表現できる
ー　例えば「Web API 取得失敗した場合表示はこうなる」という Story
MSW を使った技術記事をいくつか投稿しています：https://zenn.dev/takepepe

View Slide

段階的に自動テストを導入しよう
■　自動テスト拡充のロードマップ（例）
ー　1）ページ相当のコンポーネントを Story 登録
ー　2）MSW Storybook Addon を活用し、ページの Story を複数登録
ー　3）Storybook Play function を活用し、機能テストを追加する
ー　4）Storybook Test runner が CI で実行されるよう設定
この段階で VRT（ビジュアルリグレッションテスト）があると尚良い

View Slide

リファクタリングに取り組める状態になった
利用者 (障害無し) ✅ ーー
利用者 (障害有り) ❌ ーー

View Slide

ー　5）コンポーネントを細分化していく
ー　6）コンポーネントから処理を切り出す（関数・
Hooks）
ー　7）切り出した処理の単体テストを拡充する
ー　8）切り出したコンポーネントの a11y を当たり前品質に
「リファクタリング -> a11y 改善」を段階的に進める

View Slide

自動テスト導入を機に「 a11y の当たり前品質」も満たしていきましょう
利用者 (障害無し) ✅ ーー
利用者 (障害有り) ✅ ーー

View Slide

ご清聴ありがとうございました

View Slide

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

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

Takepepe

More Decks by Takepepe

Other Decks in Programming

Featured

Transcript