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

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

https://knowledgework.connpass.com/event/327800/

コンポーネントのテストとして採れそうな手法と、その効果を考える

Storybook もテストランナーあるんだよなあー
Vitest のブラウザモードとか

Vitest

Testing Library を組み合わせた Jest のようなコンポーネントテストがかける

Ploywright

React のコンポーネントテストできたり(experimental)

Storybook

WebdriverIO

コンポーネントテストできる

cypress

コンポーネントテストできる

Safetest

Netflix 製

単体では存在してなくてそれぞれのライブラリで対応しているってだけ？

計測

一部の計測は平等ではない。まあ難しいね

コンポーネント

Jest + Vitest など コンポーネントは Node.js でレンダリング

cypress, Playwright など ブラウザ上でレンダリング

さらにアーキテクチャが違う

WebDriver protocal とか Chrome の CDP とか
WebDriver BiDi というのが新しいプロトコル

コンポーネントテストの効果

jsdom

• 手順が少ないコンポーネントに最適
• 複雑な手順のコンポーネントだとデバッグしづらい
• ブラウザとは異なる挙動になったり

シンプルなコンポーネントにテスト必要？

• 設計を見直す機会と捉える
• テストが書きづらければ何かがおかしい…
• Copilot などで書くコストは低くなってる

ブラウザを使ったコンポーネントにテスト

• ブラウザでレンダリングされる信頼性の高さ
• E2E と比べると導入コストが低い
• ブラウザで直接確認できる
• E2E ほどではないが jsdom より実行時間長い

コンポーネント開発環境として

Storybook 開発からテストまでできる

Next.js とコンポーネントテスト

App Router とコンポーネントテストの関係がどうなっていくのか

上手に付き合うコンポーネントテスト(仮)

Visual Testing

reg-viz という同好会がある

コンポーネントテストの導入

自動テストの目的

• スピードを損なわずに開発を続ける
  • 既存の機能が問題なく動作し続けていることを担保する
  • 見た目がどのように変更されるのか、が可視化されると、レビュア側の確認コスト削減にもつながる
    • 脳内レンダリングエンジンは辛い
• はじめから導入するわけではない
  • 後から導入できるように備えておくことは重要

コンポーネントテスト with Storybook

• Storycap
  • Pupeteer でクローズする VRT
• test-runner
  • Jest + Playwright

コンポーネントテストの運用

jsdom で十分であれば、Jest/Vitest + compositeStories のテストで十分

Flaky Test ダメゼッタイ

• False Positive は自動テストの敵
• Visual Testing は画像を使うため Flaky になりやすい

VRT における閾値の調整

• 100 pixcel くらいの diff は許容
• 画像全体に対する比率であれば 0.01%
• div のみ一部差し替えたり
• それでもダメならスキップ
  • 割れ窓になるくらいならスキップ
• 遅い・不安定な状態を見逃さない

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

エンジニアの数も急増してるんだなあ

E2E テスト

• Playwright を使用
• PR のコメントすることによってマージ前に実行可能
  • PR ごとに走るよりはいいかなあ
• feature flag によってテナントを切り替える

E2E テストの役割

• 基本機能がデグレしてないか
• システム全体のテスト
• QA 確認作業の短縮
• 手動確認の手順があるとデプロイ頻度を上げられない

問題１： 同じテナントで同時にテストを実行すると落ちる

テナントプール

• 空いているテナントを自動選択する

問題２： 本番環境でテストできない

from Vercel to Cloud Run

複数プロダクトが独立してデプロイできるようにモノリスを分割

課題 開発環境限定のテスト用 API

認証を簡単にするため
本番でやるとセキュリティホールになる

テスト実行専用のゲートウェイを手前に置いた -> 実行対象をテスト用のテナントに限定

本番はインターナルアクセスのみ許可

課題 テナントのセットアップ方法がわからない

前提状態がたくさんある。初期データや外部サービスとの連携

solution: 地道に手順をドキュメント化

---

このような改善作業はしっかりとプロジェクトとして取り組んだほうがいいのだろうな