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
コンポーネントテストの手法と その効果を考える
Search
nus3
September 20, 2024
Technology
8
1.7k
コンポーネントテストの手法と その効果を考える
nus3
September 20, 2024
Tweet
Share
More Decks by nus3
See All by nus3
DenoでOpenTelemetryに入門する
yotahada3
2
460
WebDriver BiDiとは何なのか
yotahada3
1
380
フロントエンドクイズ大会
yotahada3
0
110
Node.jsのWorker threadsの話
yotahada3
1
1.2k
ワタシとPodcast
yotahada3
2
1.5k
Do you like Storybook?
yotahada3
2
4.4k
10年以上続くプロダクトの フロントエンド刷新プロジェクトのふりかえり
yotahada3
3
830
App Runner & Next.js
yotahada3
0
160
frontend-couse03
yotahada3
1
140
Other Decks in Technology
See All in Technology
AI時代の大規模データ活用とセキュリティ戦略
ken5scal
0
150
Kiroでインフラ要件定義~テスト を実施してみた
nagisa53
3
370
AIに目を奪われすぎて、周りの困っている人間が見えなくなっていませんか?
cap120
1
660
[OCI Technical Deep Dive] OracleのAI戦略(2025年8月5日開催)
oracle4engineer
PRO
1
190
家族の思い出を形にする 〜 1秒動画の生成を支えるインフラアーキテクチャ
ojima_h
3
1.2k
ロールが細分化された組織でSREと協働するインフラエンジニアは何をするか? / SRE Lounge #18
kossykinto
0
220
AIエージェントを現場で使う / 2025.08.07 著者陣に聞く!現場で活用するためのAIエージェント実践入門(Findyランチセッション)
smiyawaki0820
6
1.1k
20250807_Kiroと私の反省会
riz3f7
0
230
LTに影響を受けてテンプレリポジトリを作った話
hol1kgmg
0
370
React Server ComponentsでAPI不要の開発体験
polidog
PRO
0
310
Backlog AI アシスタントが切り開く未来
vvatanabe
1
140
「AIと一緒にやる」が当たり前になるまでの奮闘記
kakehashi
PRO
3
150
Featured
See All Featured
Documentation Writing (for coders)
carmenintech
73
5k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Docker and Python
trallard
45
3.5k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
How GitHub (no longer) Works
holman
314
140k
Building Applications with DynamoDB
mza
96
6.5k
Rails Girls Zürich Keynote
gr2m
95
14k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
283
13k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
450
Transcript
2024/09/20 Encraft #18 コンポーネントテストの手法と その効果を考える
nus3(なすさん)
今日話したいこと はじめに 各ライブラリの特徴 各ライブラリのベンチマーク 各ライブラリの違い
コンポーネントテストの効果を考える
今日話したいこと はじめに 各ライブラリの特徴 各ライブラリのベンチマーク 各ライブラリの違い
コンポーネントテストの効果を考える
お詫び 発表時間に対して スライドを作りすぎてしまいました 割愛した部分は公開したスライドを ご覧ください
コンポーネントテストとは
コンポーネントテストとは フロントエンドのコンポーネントを対象にしたテスト
コンポーネントテストとは フロントエンドのコンポーネントを対象にしたテスト ❶対象のコンポーネントをレンダリング コンポーネントテストとは
コンポーネントテストとは フロントエンドのコンポーネントを対象にしたテスト ❷レンダリングしたコンポーネントを操作 コンポーネントテストとは
コンポーネントテストとは フロントエンドのコンポーネントを対象にしたテスト ❸意図した挙動になっているか確認 コンポーネントテストとは
コンポーネントテストとして 使えるツール、ライブラリ が増えてきた
例えば Safetest Playwright Testing Library Jest Vitest (Browser Mode) 右にいくほど最近出てきたものな印象
それぞれの違いを整理し、 どのような効果があるかを 考えたい
今日話したいこと はじめに ! 各ライブラリの特徴 各ライブラリのベンチマーク 各ライブラリの違い
コンポーネントテストの効果を考える
それぞれのライブラリで コンポーネントテストを実装 使ったことないツールもあったしね
使用したライブラリ 5 Vites" 5 jsdom、Plawright(Browser Mode)、 WebdriverIO(Browser Mode 5 Playwright
5 Storybook (@storybook/test-runner 5 WebdriverII 5 Cypres8 5 Safetest
ライブラリの特徴を それぞれ、ざっくり紹介 スライド作りすぎちゃっタ
Vitest Vite-nativeなテストフレームワーy Viteと同じ設定でテストを実行できI Jestとの互換性を意識したインターフェーQ Testing Libraryを使えI
Browser Mode(experimental)ができたことで、 コンポーネントをブラウザ上にレンダリングし、 テストを実行できる
Playwright WebdriverIO 設定を切り替えるだけで 同じテストを別の動作環境で実行できる Vitest
Vitest Testing Libraryを組み合わせたJestのような記法が使える
Playwright w Mircosoftq w @storybook/test-runnerやVitestのprovider、SafeTestで 使われていp w experimentalだが、コンポーネントをブラウザ上に レンダリングし、テストを実行することも可 w
コンポーネントのbundleとserveにはViteを使っている https://playwright.dev/docs/test-components#under-the-hood
Playwright https://playwright.dev/docs/test-components#step-2-create-a-test-file-srcappspectstsx React、Svelte、Vue、SolidJSに対応
Playwright https://playwright.dev/docs/testing-library#cheat-sheet 記法は違えど、 Testing Libraryのような 書き方もできる
R コンポーネントの開発環境E R R コンポーネントの開発フロー(Chromatic$ R コンポーネントのテス6 R Chromatic 、@storybook/test-runnerを使い、
play関数に書いた内容をブラウザ上でテストできる コンポーネントのドキュメントE Interaction Testみたいな呼び方もあった気がしたけど、 新しいドキュメントではComponent testで統一されていたでござる
play関数を使った コンポーネントのテスト
PlaywrightのコンポーネントテストにStoryを使う (Portable stories) https://storybook.js.org/docs/api/portable-stories/portable-stories-playwright
PlaywrightのコンポーネントテストにStoryを使う (Portable stories) https://storybook.js.org/docs/api/portable-stories/portable-stories-playwright Portable storiesは名前からも Storybookで定義したStoryを色んなテストフレームワークで 使えるようにしたいって思いがありそう ※個人の感想です
WebdriverIO R Node.jsで実行できるブラウザ、モバイルのテスト自動化 フレームワーT R クロスブラウザに対4 R コンポーネントをブラウザ上にレンダリングし、 テストを実行できD R
Lit、Vue、Svelte、SolidJS、React、Preact、Stencil に対応 Stencil初耳だったわ
WebdriverIO Testing Libraryが使えるのでVitestと同じような記法で書ける
R コンポーネントをブラウザ上にレンダリングし、 テストを実行できX R 公式ではReact、Angular、Vue、Svelteに対1 R R Cypress Cloudというエンタープライズ向けのSaaSがあX R
テストの解析やテストの並列化など、テストに関する 機能を提供 別ライブラリに対応するためのAPIも公開してそ
spyなど独特な記法はあれど、他ライブラリと似たような 記法で書ける
Safetest t Netfilxで採用されているテストフレームワーr t コンポーネントをブラウザ上にレンダリングし、 テストを実行できH t ブラウザ上の操作にはPlaywrightを使ってH t JestやVitestのテストランナーを使えH
t セットアップが簡! t ReactなどのUIライブラリに依存しない
Safetest ここから先は Safetestを実際に使ってみて、 READMEを読んだ 程度の知識で喋ります 間違ってたら懇親会の時に優しく教えてね
Safetest Safetestのセットアップファイルを作成 アプリのエントリーポイントを指定する
Safetest アプリのエントリーポイントでSafetestのbootstrapを呼ぶ
Safetest アプリのエントリーポイントでSafetestのbootstrapを実行する このbootstrapが実行される際にglobで指定した .safetest.tsxファイルを別々にバンドル
Safetest コンポーネントのテストを書く
Safetest `s あらかじめアプリケーションを起動しておく (npm run devなどW Ts Node.js: テストの中でrender関数が呼ばれるとブラウザ上でアプリケーション の画面に遷移しようとすE
as ブラウザ: bootstarpが呼ばれると、importGlobで指定され、バンドルされた モジュール(コンポーネント)とテストケースがマッピン s ブラウザ: render関数で指定されたコンポーネント(モジュール)を importし、ブラウザ上にレンダリン 8s Node.js側に戻り、render関数以降のテストがPlaywright実行 多分、こんな流れのはず
今日話したいこと はじめに 各ライブラリの特徴 4 各ライブラリのベンチマーク 各ライブラリの違い
コンポーネントテストの効果を考える
それぞれのライブラリで テストを実行した際にかかった時間を計測
用意したコンポーネント
È3 各inputに値を入# 3 Submitボタンをクリッ Ç3 onSubmitが実行されÄ Â3 入力された値が引数に渡される 用意したテストケース
50ケースあるテストファイルを5つ用意 × 5ファイル テストの実行量はなんとなくです。特に意味はないヨ
計測したライブラリ 8 Vitest + jsdoE 8 Vitest (Browser Mode) +
Playwrigh( 8 Vitest (Browser Mode) + WebdriverIA 8 WebdriverIA 8 Storybook (@storybook/test-runner! 8 Safetest 今回実装した内容は以下のリポジトリにあるヨ (色々整ってないけど、許してネ) https://github.com/nus3/benchmark-component-test
計測しなかったライブラリ q Cypressのコンポーネントテストはデフォルトだと、ファイルごとで 並列にテストが実行されず、あまりにも実行時間が長くなったので除W q 並列で実行するにはCypress Cloudを使う必要があH q Playwrightのコンポーネントテストは用意したテストケースを満たすような テストがかけず時間切U
q コンポーネントテストでonSubmitをモックして、submit時に引数の値を 確認する方法がオラにはわからなんだ Playwrightのコンポーネントテスト、ガンガン使ってますって人がいたら、ぜひ話そ
計測に使ったスクリプト https://github.com/nus3/benchmark-component-test/blob/main/scripts/benchmark.ts 各ライブラリ、どんくらい時間かかったんやろなぁ〜ぐらいの 軽い気持ちで見てもらえると
計測結果 ※ちゃんと有意差を示すにはサンプリングの回数がもっと 必要だと思うので、あくまで参考程度に
計測結果 ※ちゃんと有意差を示すにはサンプリングの回数がもっと必要だと思うので、あくまで参考程度に ※計測した後に気づいたが一部の条件が平等ではない { StorybookとSafetestはテストの実行以外に、 Storybookのビルドやアプリのサーバー起動が必要で、 その時間を含められてなy { vitest-wdioはVitest側からproviderOptionsを使って並列に実行する設定を 渡せていない
ほんとに単純な実装しかしてないので、考慮漏れとかあれば教えてください
今日話したいこと はじめに 各ライブラリの特徴 各ライブラリのベンチマーク C 各ライブラリの違い
コンポーネントテストの効果を考える
ライブラリそれぞれで 何が違うのか
コンポーネントがレンダリングされる 場所の違い b コンポーネントはNode.js上でレンダリングされ2 b コンポーネントの操作時に使われるDOM API等は jsdomがエミュレートしてくれる + Jest
Vitest
コンポーネントがレンダリングされる 場所の違い A コンポーネントはブラウザ上でレンダリングされ% A コンポーネントの操作は実際のブラウザ上で行われる Safetest Playwright WebdriverIO
自動ブラウザテストの違い Playwright WebdriverIO ブラウザの自動操作をする際の アーキテクチャがそれぞれ違う
自動ブラウザテストの違い Playwright WebdriverIO ブラウザの自動操作をする際の アーキテクチャがそれぞれ違う アーキテクチャの違いについてはtogamiさんのZennの記事が とてもわかりやすくて、ありがたかったでござる https://zenn.dev/togami2864/articles/65af759b4a34f6
WebDriver WebdriverIO https://www.neovasolutions.com/2022/05/19/browser-automation-tools-protocols-webdriver-vs-cdp/ 標準化されたWebDriverというプロトコルを使ってブラウザを操R 各ブラウザではWebDriverプロトコルに対応したDriverを持っていH クロスブラウザに対d
間にDriverが必要で、一方向通信
Chrome DevTools Protocol(CDP) https://brahmakothapalli.hashnode.dev/playwright-01-selenium-playwright-architecture-comparison t CDPを使ってブラウザを操 t Chromiumベースのブラウザでしか使えな t PlaywrightではFirefox、Safariでも操作できるようにパッチを当てていV
t Driverが間に必要ない、またWebSocketを使った双方向通信を行なっている Playwright WebdriverIO
Native https://github.com/cypress-io/cypress-documentation/issues/872#issuecomment-586708267 ブラウザ上にCypressのテストランナーがあe 対象のコンポーネントを直接操P windowやdocumentなどブラウザ上のオブジェクトにもアクセスできe 複数タブや複数ブラウザを同時に制御できない
WebDriver BiDi c 新しいプロトコルで仕様の策定が進められていF c WebDriverの遅さ、CDPのChromium依存という 両ライブラリの問題点を解消したプロトコX c c c
Chrome、Edge、Firefoxでの実装が進んでF Puppeteer v23でFirefoxを操作する際に WebDriver BiDiがデフォルト WebDriverIOでもv9からWebDriver BiDiがデフォルトに
今日話したいこと はじめに 各ライブラリの特徴 各ライブラリのベンチマーク 各ライブラリの違い Y
コンポーネントテストの効果を考える
それぞれの違いから コンポーネントテストの 効果を考える ラストスパートだ!ここからは個人の意見だヨ!!
jsdomを使ったコンポーネントテスト Node.jsで完結する分、導入コストは低く、 実行時間も短X 操作手順が少ない(シンプルな)コンポーネントを対象と したテストに最 複雑な手順のコンポーネントを対象にしたテストは デバッグがしづらX
ブラウザ上とは異なる挙動になる場合もあd クリック可能か、z-index、フォーカス、Canvas
そもそもシンプルなコンポーネント に対するテストは必要なのか e 品質の担保というより、設計を見直す機会として捉えてW e シンプルなコンポーネントのはずなのに... テストが書きづらいぞ...何だ...何かがおかしい..` e copilotやエディタの拡張の登場もあり、コンポーネントテストを書くコストは 低くなってW
e シンプルなコンポーネントな分、テストコード自体も読みやすい→変更箇所の 対応がしやすい→不要な場合に消しやすい
ブラウザを使ったコンポーネントテスト n ブラウザ上でレンダリングされるという信頼性の高 n 挙動が違うんじゃないかという心配がいらなo n E2Eと比べると導入コストは低く、実行時間も短o n 複雑なコンポーネントのデバッグをブラウザ上で 確認できR
n experimentalなライブラリが多いが、これらがstableにな ることで、コンポーネントに対して品質を担保したい時の 第1の選択肢になりうるのでは
ブラウザを使ったコンポーネントテスト s クロスブラウザ対応はWebDriver BiDiの動向が気にな s 仕様の策定がどう進んでいくg s 各ブラウザ、テストツールはどう対応するのg s 現状、experimentalなものが多t
s ドキュメントや導入事例が十分ではないことT s E2Eほどではないが、実行時間はjsdomと比べて長そ7 s 全てのコンポーネントをブラウザ上で レンダリングし、テストする必要はない
コンポーネント開発環境として コンポーネントの開発からテストまでStorybook上で行q Storybookには、開発環境、ドキュメント、テスト、VRT などコンポーネント開発に関わる機能が揃っていI play関数を使ったコンポーネントテストのデバッグが優) ブラウザ上でテストを1ステップずつ確認できI
Storybookの環境は自前で構築してもいいし、 お金をかけてChromaticに任せちゃってもいい
キニナル点
Next.jsとコンポーネントテスト Next.js(App Router)とコンポーネントテストの関係が どうなっていくのかワタシキニナリマQ Client ComponentをテストするのはイメージできI Suspense使ってる(SSR
Streaming)コンポーネントを 対象にブラウザを使ったコンポーネントテストは できるの8 コンポーネントテスト側でも同じ挙動が 再現できるのか
ぜひ、皆さんの考えも 聞かせてください〜 本日は聞いてもろてありがとネ〜