Testing Library流でフロントエンドテストのコスパを最大化する

Transcript

1. Testing Library流でフロントエンドテストのコスパを最大 化する 2022/09/08 by eatski フロントエンドLT会 - vol.8
2. 自己紹介
3. 本名 芳賀 樹生（はが いつき） H.N eatski（いとすき） twitter https://twitter.com/eatski629
4. 現在 フリーランスのフロントエンドエンジニア Next.js+GraphQLでWebサービスの開発をしてます。 Work 何でも人狼ゲームとして遊べる汎用役職振り分けツールを公開してます https://rollrole.web.app/
5. 今回はフロントエンドのテスト（Jest,Vitest）についてお 話させていただきます LTは初めてです！！ お手柔らかにお願いします
6. フロントエンドのテストは辛い...
7. フロントエンドの特殊性 テストで動くのに本番じゃ動かない（またはその逆）が多すぎる プログラムの正しさだけを担保すればいいわけではない
8. コスパが悪い
9. テストのコスパが悪いと、良いテストが継続的に書かれていく流れを作 れない 最終的にソースコードの品質は落ちる
10. では、どうするか
11. そんな時に出会ったのが、Testing Libaryでした。
12. Testing Libraryとは Jestで動作するフロントエンド特化型のテス トヘルパー enzymeの代替 独自の思想を持つ
13. “Testing takes too much time and effort” by Kent C. Dodds （ライブラリ作者） 訳：テストには時間と労力がかかりすぎる https://testingjavascript.com/
14. 「Testing Library流」でコスパのいいテストを書こう! Testing Libraryの思想を取り込みつつ自分達の文脈に合わせていい感じにテストを書こう
15. Testing Library流について、主なポイントとして2つ解説します サンプルケース サンプルコードもあるので後ほどTwitterで共有します
16. ポイント1: 大きな粒度をテストする
17. ユーザーにとって意味のある単位をテストする 単体テストより結合テスト 内部で実装者の都合で分割された 単体 （hooksなど）をテストをしない ユーザーストーリーに沿って「データフェッチ」から「DOMのレンダリング」までを 結 合 した大きな対象(Containerコンポーネント)をテスト
18. テストケース test("API から取得したsprites.front_default を画像として表示する",async () => { render(<Pokemon id={"hoge"}/>) // TODO: assertions })
19. メリット テストの数が減る （コスト減） ドキュメントとしての価値が高まる （価値増） テストの書き直しが減る （コスト減・価値増）
20. ポイント2: UI要素のアクセシビリティをテストする
21. DOMが持つロールを参照したテストを書く ロールとは WAI-ARIAのロールのこと その要素が意味論的に何であるか・何をするかの情報 例： <article> <h1> ピッピ</h1> <!-- 略 --> </article> →「ピッピ」という名前の「見出し」ロールを持つ要素がある
22. Testing LibraryのfindByRole を使う findByRole を使うとTesting Libraryが支援技術(スクリーンリーダー等)と同じようにDOM を探索してくれる await expect( screen.findByRole("heading",{name: " ピッピ"})) .resolves.toBeInTheDocument() data-testid を振る必要がない
23. メリット 些細な実装・見た目の変更によって左右されない情報の本質についてテストできる （コ スト減・価値増） アクセシビリティを向上させるきっかけになる （価値増）
24. まとめ テストってコスパ大事！ ユーザーにとって意味のあるをテストしよう！ アクセシビリティを意識しよう！
25. ご清聴ありがとうございました