Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Testing Library流でフロントエンドテストのコスパを最大化する
Search
eatski
September 08, 2022
3
1.2k
Testing Library流でフロントエンドテストのコスパを最大化する
eatski
September 08, 2022
Tweet
Share
More Decks by eatski
See All by eatski
GPTを使った水平思考クイズの投稿サイトを作ってみた
eatski
0
180
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
32
6.4k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
Making Projects Easy
brettharned
116
6k
The Invisible Side of Design
smashingmag
299
50k
How to train your dragon (web standard)
notwaldorf
91
5.9k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.4k
What's in a price? How to price your products and services
michaelherold
244
12k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Bash Introduction
62gerente
611
210k
Practical Orchestrator
shlominoach
186
10k
Become a Pro
speakerdeck
PRO
26
5.2k
Transcript
Testing Library流でフロントエンドテストのコスパを最大 化する 2022/09/08 by eatski フロントエンドLT会 - vol.8
自己紹介
本名 芳賀 樹生(はが いつき) H.N eatski(いとすき) twitter https://twitter.com/eatski629
現在 フリーランスのフロントエンドエンジニア Next.js+GraphQLでWebサービスの開発をしてます。 Work 何でも人狼ゲームとして遊べる汎用役職振り分けツールを公開してます https://rollrole.web.app/
今回はフロントエンドのテスト(Jest,Vitest)についてお 話させていただきます LTは初めてです!! お手柔らかにお願いします
フロントエンドのテストは辛い...
フロントエンドの特殊性 テストで動くのに本番じゃ動かない(またはその逆)が多すぎる プログラムの正しさだけを担保すればいいわけではない
コスパが悪い
テストのコスパが悪いと、良いテストが継続的に書かれていく流れを作 れない 最終的にソースコードの品質は落ちる
では、どうするか
そんな時に出会ったのが、Testing Libaryでした。
Testing Libraryとは Jestで動作するフロントエンド特化型のテス トヘルパー enzymeの代替 独自の思想を持つ
“Testing takes too much time and effort” by Kent C.
Dodds (ライブラリ作者) 訳:テストには時間と労力がかかりすぎる https://testingjavascript.com/
「Testing Library流」でコスパのいいテストを書こう! Testing Libraryの思想を取り込みつつ自分達の文脈に合わせていい感じにテストを書こう
Testing Library流について、主なポイントとして2つ解説します サンプルケース サンプルコードもあるので後ほどTwitterで共有します
ポイント1: 大きな粒度をテストする
ユーザーにとって意味のある単位をテストする 単体テストより結合テスト 内部で実装者の都合で分割された 単体 (hooksなど)をテストをしない ユーザーストーリーに沿って「データフェッチ」から「DOMのレンダリング」までを 結 合 した大きな対象(Containerコンポーネント)をテスト
テストケース test("API から取得したsprites.front_default を画像として表示する",async () => { render(<Pokemon id={"hoge"}/>) //
TODO: assertions })
メリット テストの数が減る (コスト減) ドキュメントとしての価値が高まる (価値増) テストの書き直しが減る (コスト減・価値増)
ポイント2: UI要素のアクセシビリティをテストする
DOMが持つロールを参照したテストを書く ロールとは WAI-ARIAのロールのこと その要素が意味論的に何であるか・何をするかの情報 例: <article> <h1> ピッピ</h1> <!-- 略
--> </article> →「ピッピ」という名前の「見出し」ロールを持つ要素がある
Testing LibraryのfindByRole を使う findByRole を使うとTesting Libraryが支援技術(スクリーンリーダー等)と同じようにDOM を探索してくれる await expect( screen.findByRole("heading",{name:
" ピッピ"})) .resolves.toBeInTheDocument() data-testid を振る必要がない
メリット 些細な実装・見た目の変更によって左右されない情報の本質についてテストできる (コ スト減・価値増) アクセシビリティを向上させるきっかけになる (価値増)
まとめ テストってコスパ大事! ユーザーにとって意味のあるをテストしよう! アクセシビリティを意識しよう!
ご清聴ありがとうございました