テスト
ソフトウェアの品質を担保するためのもの
フロントエンドのテスト(画面)
開発者が望んだように、ユーザーがちゃんとページを見れることや、機能を使用できるかどうかなど
バックエンドのテスト(DB)
実際にデータベースから削除されたかどうかなど
メリット
- エラーの早期発見
- ホットフィックスを防ぐ
- チェック漏れができる(国際化対応やアクセシビリティ)
難しい理由
- 要件が変わりやすい(デザインなどは変わってしまう)
- とくにスタートアップなど
- ツールの移り変わりが激しい
- テスト手法が多すぎるし、複雑
- Reactなどが最近出てきたので、知見もたまっていない
- バックエンドと比べてクリティカルでないので、書いても効果を実感しづらい
- 費用対効果が悪い
種類
Testing Pyramid(テスティングピラミッド)
- E2Eテストは書くのが大変で実行速度も遅い
- ユニットテストが一番あるべき
- 現代は主流でなくなりつつある
TESTING TROPHY(テスティングトロフィ)
- 現在主流になりつつある
- Testing Libraryの作者 Kent C. Doddsが提唱
- Next.jsの開発元のVercel CEOのGuillermo Raunchも同様の発言をしていた
- スタティックテストが追加
- 自信係数
- 図の上行にくほど、正しく動くことへの自信を与える
- 量が多いほど書くべきテストを増やすべき
- インテグレーションテストが最もコスパが良い
ユニットテスト(単体テスト)
- 関数やメソッドのテスト(ほぼ同じ)
- 関数
- 独立して定義されたもの
- メソッド
- クラスで定義されているもの
- 関数
- APIのテストにも有効だが、本番のAPIではなく、モックを使用する
- Meta製のJestが安定で最も使われている
- Vitestが人気が出ている
- 速度が早い
- 設定がかんたん
インテグレーションテスト(結合テスト)
- ユニット相互作用のテスト
- 複数の機能がうまく連動しているかどうかを調べる
- Testing Library
- getByTestIdは最終手段
E2Eテスト(エンドツーエンドテスト)
- ブラウザを動作して行うインタラクションテスト
- コードや実装とは一切関係なくユーザーからアプリケーションがどう見えるかどのようにアプリケーションを動かすかという点のみ扱う
- モックではなく、実際のAPIを使いブラウザで実行されることが特徴
- Cypressが最も使われていて安定
- Microsoft製のPlaywrightが人気
- ユーザーの操作からコードを生成できる
スタティックテスト(静的テスト)
- フォーマットやタイプミス、型のテスト
- ESLint, Prettier, TypeScript
スナップショットテスト
- UIが変更されていないかを確認
- スナップショット(プログラムの出力)を取得し、過去のスナップショットファイルと比較する
- Jest
ビジュアルリグレッションテスト
- コードの変更によって生じる視覚的な差異など視覚的な構造のテスト
- ページやコンポーネントのスクリーンショットを過去のスクリーンショットと比較する
- Percyのような専用ツールをCypressやPlaywrightなどのE2Eツールと組み合わせて使うことが多い
- 最近はUIコンポーネント管理のツールのStroybookがリグレッションテストに使われている
パフォーマンステスト
- 従来は手作業で行われることが多かったが、最近はCIで自動化させることも多い。パフォーマンスの許容値を設けてそれを下回った場合はデプロイさせない
- LighthouseやPageSpeed Insightsなど
アクセシビリティテスト
- アクセシビリティ標準の基準に従って、インターフェースをテスト
- 障害のある人がWebサイトへアクセスしたときに効果的に使用できるようにするもの
- スクリーンシーダー、AccessLint、axe-core、Lighthouse、pa11yなど