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
1k
Testing Library流でフロントエンドテストのコスパを最大化する
eatski
September 08, 2022
Tweet
Share
More Decks by eatski
See All by eatski
GPTを使った水平思考クイズの投稿サイトを作ってみた
eatski
0
110
Featured
See All Featured
Pencils Down: Stop Designing & Start Developing
hursman
117
11k
Navigating Team Friction
lara
179
13k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
8.9k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
14
1.5k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
79
43k
A Philosophy of Restraint
colly
197
16k
Done Done
chrislema
178
15k
Mobile First: as difficult as doing things right
swwweet
217
8.6k
What’s in a name? Adding method to the madness
productmarketing
PRO
17
2.7k
In The Pink: A Labor of Love
frogandcode
138
21k
Git: the NoSQL Database
bkeepers
PRO
423
63k
Fontdeck: Realign not Redesign
paulrobertlloyd
76
4.9k
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 を振る必要がない
メリット 些細な実装・見た目の変更によって左右されない情報の本質についてテストできる (コ スト減・価値増) アクセシビリティを向上させるきっかけになる (価値増)
まとめ テストってコスパ大事! ユーザーにとって意味のあるをテストしよう! アクセシビリティを意識しよう!
ご清聴ありがとうございました