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.2k
コンポーネントテストの手法と その効果を考える
nus3
September 20, 2024
Tweet
Share
More Decks by nus3
See All by nus3
フロントエンドクイズ大会
yotahada3
0
28
Node.jsのWorker threadsの話
yotahada3
1
420
ワタシとPodcast
yotahada3
2
970
Do you like Storybook?
yotahada3
2
4k
10年以上続くプロダクトの フロントエンド刷新プロジェクトのふりかえり
yotahada3
3
730
App Runner & Next.js
yotahada3
0
110
frontend-couse03
yotahada3
1
91
frontend-couse02.pdf
yotahada3
0
56
Frontend couse01
yotahada3
0
190
Other Decks in Technology
See All in Technology
OPENLOGI Company Profile for engineer
hr01
1
12k
Consoles, printk, Nested-NMIs_ Oh my!
ennael
PRO
0
140
FastAPIでのasync defとdefの使い分け
takashi1029
6
1.7k
仮想化って何だろう
shkoga
0
130
Create Inquiry via Bedrock / 生成 AI で問い合わせ品質は変わるのか?思いついてぱっと作ったものを供養してみる
kazzpapa3
1
190
DockerのマルチプラットフォームイメージをGitHub Actionsでビルドして公開する際に、参考にしたドキュメントと便利だったツール
iwamot
3
120
Amazon BedrockとPR-Agentでコードレビュー自動化に挑戦・実際に運用してみた
diggymo
0
540
【shownet.conf_】ShowNet x 宇宙ネットワーク
shownet
PRO
0
270
ITエンジニアとして知っておいてほしい、電子メールという大きな穴
logica0419
1
250
Vista FinderMx
jtes
0
160
【shownet.conf_】AI技術とUX監視の応用でShowNetの基盤を支えるモニタリングシステム
shownet
PRO
0
240
【shownet.conf_】ローカル5Gを活用したウォーキングツアーの体感向上
shownet
PRO
0
220
Featured
See All Featured
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
A Philosophy of Restraint
colly
202
16k
4 Signs Your Business is Dying
shpigford
180
21k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.9k
Learning to Love Humans: Emotional Interface Design
aarron
271
40k
The Cost Of JavaScript in 2023
addyosmani
43
5.8k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
What's in a price? How to price your products and services
michaelherold
243
11k
A designer walks into a library…
pauljervisheath
201
24k
We Have a Design System, Now What?
morganepeng
48
7.1k
Rails Girls Zürich Keynote
gr2m
93
13k
Embracing the Ebb and Flow
colly
83
4.4k
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 コンポーネントテスト側でも同じ挙動が 再現できるのか
ぜひ、皆さんの考えも 聞かせてください〜 本日は聞いてもろてありがとネ〜