テスト自動化のすすめ
みなさんテストはしていますか？
学生の開発の場合完成することが優先で、そこまでテストはしてこなかったと思いますが社会人になるとそうはいきません。
同じテスト内容・テスト結果であれば、手作業・目視で確認するのはあまりに非効率です。自動化して、楽になりたいと思いませんか？
テストの種類によっては自動化できるものと自動化が難しいものがあり、各テストの自動化の実装コストとメンテナンスコストについて考えました。
テストの種類
アプリケーション開発におけるテストの種類
・単体テスト
・システムテスト
・レグレッションテスト
・UIテスト
・パフォーマンステスト
・セキュリティテスト
・クロスブラウザテスト
・モバイルテスト
単体テスト
概要:
最小単位のコード（関数、メソッド、クラスなど）を対象に、その動作が期待通りであるかを確認するテスト。外部依存を排除し、単独で機能することを保証します。
例:
数値を2倍にする関数 double() が、入力5に対して10を返すかを確認。
// 対象の関数
function double(num) {
return num * 2;
}
// Jestを使ったテスト
test('double() 関数は入力5に対して10を返す', () => {
expect(double(5)).toBe(10);
});
Jest等で単体テスト導入できます！
システムテスト (System Test)
概要: アプリケーション全体が仕様通りに動作するかを検証します。
例: 開発したアプリ全体が要件に基づいて期待通り動作するかを確認。
レグレッションテスト (Regression Test)
概要: 新しい機能や修正が既存の機能に影響を与えていないかを確認するテスト。多くの場合、自動化が推奨されます。
例: 新しい機能追加後に、以前の機能が壊れていないかを検証。
APIのレグレッションテストであればPostman(Newman)がおすすめです！
UIテスト (User Interface Test)
概要: ユーザーインターフェースの動作を確認するテスト。E2Eテストの一部とも重なることがあります。
例: ボタンがクリック可能で、指定されたアクションを正しくトリガーするかを確認。
UIのレグレッションテストはPlaywrightがおすすめです！
パフォーマンステスト (Performance Test)
概要: アプリケーションの速度、スケーラビリティ、リソース消費を評価するテスト。
例: サーバーが1,000リクエスト/秒を処理できるかを測定。
パフォーマンステストはk6がおすすめです！
セキュリティテスト (Security Test)
概要: アプリケーションがセキュリティ要件を満たしているかを検証します。
例: SQLインジェクションやXSSの脆弱性がないかをチェック。
クロスブラウザテスト (Cross-Browser Test)
概要: アプリケーションが異なるブラウザやデバイスで正しく動作するかを確認します。
例: Chrome、Firefox、SafariでのUIの動作確認。
Playwrightでクロスブラウザテストできます！
モバイルテスト (Mobile Test)
概要: モバイルアプリケーション固有の動作をテスト。
例: スワイプやピンチ操作が期待通りに動作するかを確認。
各テストの実装コストとメンテナンスコスト
| テストの種類 | 実装 コスト |
メンテナンス コスト |
コメント |
|---|---|---|---|
| 単体テスト | 低 | 低 | 小規模なコード単位をテストするため、実装・メンテナンスともに比較的簡単。まずはこれの自動化をやる。 |
| システムテスト | 中 | 中 | アプリ全体の統合動作をテスト。複数のコンポーネント間のやり取りを考慮する必要があるため実装が複雑になるが、変更頻度が低ければメンテナンスは安定しやすい。 |
| レグレッションテスト | 中 | 中 | 自動化が進んでいると効率的だが、対象範囲が広くなるほど管理が難しい。新しいバグや変更に合わせてテストケースを更新する必要がある。APIはCIにNewmanを入れておくとテスト組み込みが簡単で良い。 |
| UI テスト | 高 | 高 | UI 変更の影響を受けやすく、テストケースの修正が頻繁に必要。Playwrightなどで自動化している場合、エレメントの識別方法が壊れるとメンテナンスコストが急増。 |
| パフォーマンステスト | 中 | 低 | 専用ツール（k6 や Gatling など）のセットアップが必要なため初期コストが高い。リソースや負荷シナリオの変更に対応するための更新が必要になるがそれほど多くない。 |
| セキュリティテスト | 高 | 低 | セキュリティ脆弱性の特定には専門知識が必要で実装コストが高いが、自動化の更新頻度はそこまで高くない。特にペネトレーションテストの部分は手動検査が必要なことも多い。 セキュリティテストは、セキュリティツールやセキュリティチームに依頼する方がいいかも。 |
| クロスブラウザテスト | 高 | 高 | 各ブラウザでの動作を確認するため、Playwright などのツールが必要。Playwright側でクロスブラウザに対応していればコストはUIテストと同じ。 |
| モバイルテスト | 高 | 高 | 実機テスト環境の構築や多種多様なデバイス対応のために実装コストが高い。OS やデバイスごとの仕様変更に追随するため、メンテナンスコストも高くなりがち。エミュレータでは実機の動作を模倣するけど、ハードウェアやネットワーク環境、OSやファームウェアやスワイプの動作が異なる場合があるため実機テスト用のテストを別に用意しないといけない。 |
総評
- 低コストで済むのは単体テスト：最小限の範囲でコードの動作確認が可能なため、実装・メンテともに負担が少ない。
- 高コストになるのはUIテストとモバイルテスト：UIの頻繁な変更や多様なデバイス対応が必要なため、労力がかかる。個人的にはメンテナンスコスト的に自動化するのは最後の最後で良い。
- セキュリティテストは専用ツールの導入を入れれば、更新頻度はそこまでない。
まずは単体テストのから自動化を初めてみましょう。