『フロントエンド開発のためのテスト入門』を読んだ
読書メモ自動テスト
『フロントエンド開発のためのテスト入門 今からでも知っておきたい自動テスト戦略の必須知識』を読んだので，概要をまとめます
注意：まとめにはこの記事を書いた者の解釈が多分に含まれています
テスト手法
| 手法名 | 対象 | 特徴 |
|---|---|---|
| 関数単体テスト | 関数 | テストの最小単位 |
| UIコンポーネント単体テスト | フロントエンドに閉じたUIコンポーネントの機能 | |
| UIコンポーネント結合テスト | フロントエンド以外にも関係するUIコンポーネントの機能 | サーバーとの通信を行うなどフロントエンド領域の外部とデータの送受信を伴うUIコンポーネントのテスト．フロントエンド外部領域のモックアップを使用する． |
| UIコンポーネントビジュアルリグレッションテスト | UIコンポーネントのスタイルの変更の有無 | UIコンポーネントのスタイルがある特定時点と比べて変更されたかどうかをテストする． |
| E2Eテスト | フロントエンド領域全体 | ヘッドレスブラウザを用いて，ブラウザが提供するAPI，画面遷移，DBサーバーへの接続，外部ストレージへの接続なども含めてテストする |
テストの目的
- 壊れていないことを短時間で保証すること
| 誰が | いつ | 恩恵 | 補足 |
|---|---|---|---|
| 開発者 | 設計・初期開発 | 設計が不適切であることを検知できることがある． | テストが書きづらいということは，適切でない設計（責務の切り分け不足，アクセシビリティの欠如）をしている可能性がでてくる． |
| 開発者 | リファクタ・新機能追加 | 既存の機能が壊れていないことを保証できる | |
| 開発者 | コードで仕様を理解しようとするとき | テストコードを見れば，仕様がある程度わかる | テストコードには何をテストするかが書かれている（タイトルと実体が乖離する可能性も当然あるので注意）． |
| レビュワー | レビュー | レビュー対象を絞り込むことができる | 既存の機能が壊れていないことが保証されるため，レビュー対象以外への外部影響を考えなくて良い |
| サービス提供者全体 | ライブラリアップデート時 | 脆弱性への迅速な対応が可能 | ライブラリアップデート時に壊れていないことを保証できる |
テストタイプ
- ソフトウェアテストで有名なテストタイプとWebフロントエンドテストにおけるテストの対応
| テストタイプ | フロントエンドでのテスト | 目的 | 補足 |
|---|---|---|---|
| 機能テスト | インタラクションテスト | 開発対象の機能に不具合がないかテストする | フロントエンドにおいてはUIコンポーネントへの操作を行ったときの機能をテストする |
| 非機能テスト | アクセシビリティテスト | ユーザーの要求があいまいで仕様書に起こしづらいことをテストする | Webフロントエンドにおいてはアクセシビリティが代表例 |
| リグレッションテスト | ビジュアルリグレッションテスト | 特定時点からの見た目の差分を検出して，不具合が起きていないことを確認する | - |
テスト戦略
- テストピラミッド型
- 「Succeeding with Agile」（Mike Cohn）
- メンテナス工数が低く短時間で実行できる単体テストを充実させて，逆の性質を持つE2Eテストを少なくする
- 逆にE2Eテストが肥大化している状態をアイスクリームコーン型という
- テスティングトロフィー型
- Testing Library - Kent C. Dodds.
- Webフロントエンドでは単体テストのみで済むことは少なく，結合テストを充実させるべきという考え方