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.4k
コンポーネントテストの手法と その効果を考える
nus3
September 20, 2024
Tweet
Share
More Decks by nus3
See All by nus3
フロントエンドクイズ大会
yotahada3
0
41
Node.jsのWorker threadsの話
yotahada3
1
690
ワタシとPodcast
yotahada3
2
1.1k
Do you like Storybook?
yotahada3
2
4.1k
10年以上続くプロダクトの フロントエンド刷新プロジェクトのふりかえり
yotahada3
3
760
App Runner & Next.js
yotahada3
0
120
frontend-couse03
yotahada3
1
100
frontend-couse02.pdf
yotahada3
0
62
Frontend couse01
yotahada3
0
210
Other Decks in Technology
See All in Technology
LINEスキマニにおけるフロントエンド開発
lycorptech_jp
PRO
0
350
AWS環境におけるランサムウェア攻撃対策の設計
nrinetcom
PRO
0
220
pg_bigmをRustで実装する(第50回PostgreSQLアンカンファレンス@オンライン 発表資料)
shinyakato_
0
120
スケールし続ける事業とサービスを支える組織とアーキテクチャの生き残り戦略 / The survival strategy for Money Forward’s engineering.
moneyforward
0
110
12 Days of OpenAIから読み解く、生成AI 2025年のトレンド
shunsukeono_am
0
580
ネットワーク可視化の世界
likr
6
4.3k
プロダクト組織で取り組むアドベントカレンダー/Advent Calendar in Product Teams
mixplace
0
430
「完全に理解したTalk」完全に理解した
segavvy
1
180
re:Invent をおうちで楽しんでみた ~CloudWatch のオブザーバビリティ機能がスゴい!/ Enjoyed AWS re:Invent from Home and CloudWatch Observability Feature is Amazing!
yuj1osm
0
140
サイバー攻撃を想定したセキュリティガイドライン 策定とASM及びCNAPPの活用方法
syoshie
3
1.5k
最近のSfM手法まとめ - COLMAP / GLOMAPを中心に -
kwchrk
7
1.4k
Yahoo! ズバトクにおけるフロントエンド開発
lycorptech_jp
PRO
0
110
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
Being A Developer After 40
akosma
89
590k
Reflections from 52 weeks, 52 projects
jeffersonlam
347
20k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.2k
The Invisible Side of Design
smashingmag
299
50k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
460
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.2k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
GraphQLとの向き合い方2022年版
quramy
44
13k
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 コンポーネントテスト側でも同じ挙動が 再現できるのか
ぜひ、皆さんの考えも 聞かせてください〜 本日は聞いてもろてありがとネ〜