フロントエンド開発のためのテスト入門

なぜテストを書くか

• 事業の信頼のため
• 健全なコードを維持するため
• 実装品質に自信を持つため
• 円滑なコラボレーションのため
• リグレッションを防ぐため

リグレッション：いわゆる先祖返り

テストを書く障壁

• テストコーディングスキルが身についていない
  • コピペでもいいから始めてみる
• テストを書く時間がない
  • 自動テストコードは必要なものである、という合意をチーム内に作る
  • フロントエンドは短期間で陳腐化するからテスト書かなくて良い？
    • 半年でデザインをリニューアルすることもある、機能を維持してフロントだけ改修する機会で役に立つ
• テストを書くと時間が節約できる？
  • バグが起きる前提を踏まえると、テストを書いた方が時間が節約できる
• テストを全員が書くためには？
  • 前例を用意しておけば、他のメンバーもまねしやすい
  • 後でテストを書くのは調整が大変

テストの種類

1. ライブラリが提供する関数
2. ロジックを担う関数
3. UIを表現する関数
4. Web APIクライアント
5. APIサーバー
6. データベース

• 静的解析
  • ②と③の間、③と④の間など
  • 隣接するモジュール連携感の不整合を検証できる
• 単体テスト
  • ②のみ、③のみ
  • モジュール単体が提供する機能を検証できる
  • コーナーケースの検証に向いている
• 結合テスト
  • ①〜④まで、②〜③まで
  • モジュールをつなげることで提供できる機能を検証できる
  • 広範囲をざっくりと検証するようなテストになりがち
• E2Eテスト
  • ①〜⑥
  • 最も広範囲を検証できる
  • 稼働状況に忠実なテスト
• E2Eテスト

テストの目的

• 機能テスト（インタラクションテスト）
  • フロントエンドの機能テストはインタラクションテストとほぼ同義になりがち
  • ヘッドレスブラウザ＋UIオートメーションを使用して自動テストを書く
• 非機能テスト（アクセシビリティテスト）
• リグレッションテスト
  • 前後の差分から想定外の不具合が発生していないかを検証
  • フロントエンドにおいてはビジュアルを持つUIコンポーネントが大部分を占めるので、ビジュアルリグレッションテストが重要視される

フロントエンドテストの範囲

• 静的解析
  • TSとかESLintとか
• 単体テスト
  • 入力から期待する出力が得られるかをテストする
  • UIコンポーネントにおいては、Propsから期待するHTMLが出力されるかをテストできる
  • モジュールによっては例外をスローする条件を確かめて考慮漏れに気づきやすくできる
• 結合テスト
  • 複数のモジュールが連動する機能を検証する
  • 複数モジュールを連動させてインタラクションを通して検証する
  • 各テストの目的を明確にして実施する
• E2Eテスト
  • フロント以外を含むすべてを検証する

フロントエンドテストの目的

• 機能テスト（インタラクションテスト）
  • ^^^^^^^^^^
• 非機能テスト（アクセシビリティテスト）
• ビジュアルリグレッションテスト