第一回フロントエンド開発テスト入門読書会をスタートしました。

フロントエンド開発テスト入門読書会とは

本日から話題の書籍「フロントエンド開発テスト入門」の勉強会をスタートしました。

毎週月曜日に30分間の時間で実施されています。参加者は指定された部分まで事前に読んできて、勉強会では議論や実際のコードを動かす時間を共有しています。

今回は1章と2章を読んできての良かった点や感想の共有と深掘りしたい部分の議論を行いました。

書籍：フロントエンド開発テスト入門

良かった点＆感想など

高橋

• テストを書く目的
  • 事業の信頼のため（バグを生まない）
  • 健全なコードを維持するため（積極的なリファクタリングを推し進める）
  • 実装品質に自信を持つため（→テストコードが書きづらいのは密結合になっているサイン）
  • 円滑なコラボレーションのため（コードを読みやすくする）
  • リグレッションを防ぐため（自動テストによって想定外の見た目のリグレッションを防げる）
• テストを書く障壁
  • 学習コスト：
    • 他の人のコードを見て学ぶのが一番良い
    • テストに不慣れなメンバーでも前例があればある程度のテストが書けるようになる
  • テストを書く時間の確保：
    • リグレッションの発生が起こると運用段階で時間を浪費してしまう。トータルで見ると、自動テストのコードを早期にコミットしていた方が時間の節約になる
• 範囲と目的で考えるテスト範囲
  • 静的解析：
    • TypeScriptやESLintなど。「隣接するモジュール関連系の不整合」に対して検証
  • 単体テスト：
    • 「モジュール単体が提供する機能・関数」のテスト。コーナーケースの検証に向いている。
  • 結合テスト：
    • 「モジュールをつなげることで提供できる機能」のテスト。
  • E2Eテスト：
    • ヘッドレスブラウザ＋UIオートメーションで実施するテスト。範囲が広いほどテスト対象を効率よくカバーできる。

  目的

  • 機能テスト（インタラクションテスト）：機能のテスト
  • 非機能テスト（アクセシビリティテスト）：心身特性に隔てのない製品を提供できるているか
  • リグレッションテスト：前後の差分を検出して想定外の不歩合が発生していないか検証するテスト
• テスト戦略モデル
  • 「コスト配分」をどのように設計して最適かを行うかがテスト戦略最大の検討事項
  • テストピラミッド型
    • 上層のテストは実行時間に関するコストが高いため、仮想のテストを充実させることで、安定かつ高速なテスト戦略とすることができる。
  • テスティングトロフィー型
    • 結合テストに最も比重を置くべきという考え
    • Webフロントエンド開発において、単体のUIコンポーネントだけで成立する昨日はほとんどないため、ユーザー操作を起点とした結合テストを充実させることこそが、より良いテスト戦略になるという意図が込められている

種井

• 内容
  • 単体テスト
    • SPAにおいてUIコンポーネントはテストしやすい対象
      • 関数の単体テストと同じ要領でテストができる
  • ブラウザがなければ成立しない機能テストは一定存在する（仮想ブラウザ環境では提供されないものがある）
    • スクロールやセッションストレージを含めたテスト
  • ビジュアルリグレッションテスト
    • 面白い。どうやって実現するのか気になる
    • 網羅できていればレイアウト崩れは一発で検知できる
  • テスト戦略
    • テストピラミッドはフロントエンドの自動テストにおいても適用される
• メモ
  • 良いテストを書くにはテスト対象となるコードが良い設計になっている必要がある
  • テストを書くことによるメリットを実際に経験しないと、テストを書く文化は浸透しなさそう
    • 長期的な目線が必要だから、尚更意識していないと効果は理解されづらい
  • 現在関わっている開発ではUIコンポーネントと言われてもあまりピンと来ない

 谷

• メリット
  • テストコードが書けると、UIコンポーネントやカスタムフックの責務分離が意識的にできる
  • Webアクセシビリティへのアプローチが意識的に出来る
  • コードに対して、優れた補足情報になる
    • 追加したコード + 仕様書 + テストコードがそろっているPRが開発速度に良い影響を与える
    • ランサーズで、上記すべてがしっかり揃っているPRはあまり見ない
  • テストを書くことは、短期的には個人の時間が取られるが、長期的にはチームの時間が節約できる
• メモ
  • Storybookとモックサーバーは普通に案件利用している
    • 厳密なテストは書いていない
  • ランサーズでフロントエンドのテストコード活動を始める場合
    • ReactプロジェクトがESLintに怒られまくってるので、それを解消する活動から
    • 上記と並行してStorybookを導入して、Storyファイルを作る
    • フロントエンドのDependabotが放置されているので、それも見る

ディスカッション

• reg-suit
  • https://zenn.dev/toshiokun/articles/3d7087b84ba1d9