Zenn
💭

Frontendのテスト全部知る 〜Unit TestからE2Eまで〜 - Encraft #18 イベントレポート(オンライン)

2024/09/21に公開
イベントレポート
tech

Frontendのテスト全部知る 〜Unit TestからE2Eまで〜 - Encraft #18

興味深かったことのみ列挙して感想を書きます

資料

コンポーネントテストの手法と その効果を考える

  • コンポーネントテストの手法と その効果を考える - Speaker Deck
  • 各ライブラリのベンチマーク
    • 速度的には Safatest, Vitest+jdom あたりが速い(一部条件が一致しておらず参考程度だそう)
    • 下記は除外したのだそう
      • Cypress は並行実行に Cypress Cloud が必要
      • Playwight のコンポーネントテストで onSubmit をモックして submit 時の引数値を確認する方法がわからなかったそう
  • コンポーネントテストの違い
    • コンポーネントがレンダリングされる場所の違い: Node.js or ブラウザ上
      • Node.js: Jest, Vitest + jsdom
      • ブラウザ上: Storybook, Cypress, Playwight, Safetest, WebdriverIO
    • 自動ブラウザテストの違い: アーキテクチャの差異
  • コンポーネントテストの効果
    • jsdom を使ったコンポーネント
      • メリット
        • 操作手順の少ないコンポーネントが適している
        • Node.jsで完結するため導入コストが低く実行時間も短い
      • デメリット
        • 複雑な手順のコンポーネントはデバックがしづらい
        • ブラウザ上とは異なる場合がある
          • クリック可能か、z-index、フォーカス、Canvasなど
      • シンプルなコンポーネントでテストは必要か
        • テストが書きづらい場合は設計を見直すべき
    • ブラウザを使ったコンポーネントテスト
      • メリット
        • ブラウザでレンダリングするため信用性の高さ
        • E2Eと比べると導入コストが低く実行時間も短い
        • デバックがしやすい
      • デメリット
        • experimental も多い
          • stable になればコンポーネントテストの第一の選択になりそう
        • 実行時間は jsdom に比べたら長そう
          • 全コンポーネントをブラウザ上でレンダリングしてテストする必要はない
      • 今後 WebDriver BiDi の動向に注目
    • Storybook で開発からテストまで行う
      • コンポーネント開発の一通りが揃っている
      • デバックが優秀
      • 構築はお金があれば Chromatic に任せても良い

上手く付き合うコンポーネントテスト

  • 上手に付き合うコンポーネントテスト - Speaker Deck
  • 自動テストはスピードを損なわず開発を続けるため
    • コンポーネントテストもスピードを求められる
    • 見た目がどのように変化するか可視化されるとレビューアーの確認のしやすさにつながる
  • プロジェクト立ち上げ時は見送るのは大事。ただ今後に備えておく
  • StorybookはUIコンポーネント開発基盤として寡占状態
    • 他のツールは現状勝てない
    • Jestなどの自動テストと連携する機能に力を入れている
    • コンポーネントテストの備えとして有効
  • 連携ツール
    • Chromatic: Storyオフィシャル。お金があるならこれで良い
  • CIの実行時間
    • 会場では10分まで我慢できる方が多い
    • 開発速度を上げたいのにCIに時間がかかるのは本末転倒
  • CIを早くする方法
    • 並列実行(ワーカーレベル)
      • 実行ブラウザ (worker) を増やす
    • 並行実行(ジョブレベル)
      • CI実行環境ごとに並列化する
        • GithubAction だと matrix
    • ランナーを使い分ける
      • jsdom で十分なケースであれば遅くなりにくい
        • 例えばフォームバリデーションや aria 属性の確認
  • Flaky Test (成功失敗が安定しないテスト) はだめ
    • VRT が起こりやすい
      • 閾値は 100px は許容できる
      • 画面全体に対する比率は 0.01%
    • iframeなどをdivなどに部分的な差し替え
    • それでもダメなら skip 割れ窓化を防止

急拡大する開発組織を支えるナレッジワークの E2E テスト基盤

  • 急拡大する開発組織を支えるナレッジワークの E2E テスト基盤 - Speaker Deck
  • QAエンジニアがテストケースの管理と健康状態を監視
    • QAエンジニアをペアプロでスキル継承
  • E2Eテストの役割
    • 基本ケースのデグレがないこと
    • モジュール単位のテストは不安定なシステム全体をテスト
    • QA確認作業を自動化
  • 直面した課題
    • テスト環境が2つしかなかった
      • テナントプールによる空いているテナントで自動選択して実行
    • 認証が本番環境で対応していない
      • テスト実行専用のゲートウェイを設けて実装
    • テナントのセットアップ方法が不明
      • みんなで地道に調査してドキュメント化

感想

  • コンポーネントテストの手法も銀の弾丸はなく、今は混沌としていることがわかった
    • ブラウザを使ったコンポーネントテストが experimental から stable になればある程度スタンダードにはなりそうな気配
    • Playwight のコンポーネントテストのイメージはあまりなかった
      • まだ experimental らしく発表を聞く限りハマりどころがありそう
  • ブラウザテストのアークテクチャはとても興味深かった
  • コンポーネントテストも使い分けが必要
    • とくに Node.js とブラウザのテストの違いは大きい
      • 今のテーマは jsdom 中心で書きづらいデバックしにくいはチームの不満としてある
  • CIの遅さやFlaky Testは耳が痛い
    • やりたいと思いつつ工数的に手が回っていない・・・

Discussion