はじめに
前回の記事「はじめての手動テスト」では、Excelでテストケースを作成し手動でテストを実施しました。
テストを進める中で「テストコード」について今回あらためて調べてまとめました。
1. テストコードとは
開発したプログラム（本番コード）が意図した通りに動作するかを自動的に検証する専用のコードです。「特定の入力に対して正しい出力が得られるか」を自動でチェックします。
手動で確認するのも大事ですが、毎回手で動かすのは大変でミスも起きやすいです。
テストコードを使えば自動で何度でも確認できるため、抜け漏れも減らすことができます。
主に以下の3つの場面で役立ちます。
- バグの早期発見：手動では見逃してしまうような小さなバグも発見できる
- 手動確認の手間削減：自動で実行できるため、確認作業の負担が減る
- デグレード防止：仕様変更後も既存の機能が正しく動作しているか確認できる
2. テストコードの種類
単体テスト
関数やクラスなど小さな単位が意図どおりに動くかを検証します。
結合テスト
複数の機能を組み合わせたときの連携が正しく行われるかを検証します。
回帰テスト
過去の不具合が再発していないかを確認し、品質の維持を担保します。
3. テストコードを書くデメリット
仕様変更に伴うメンテナンスの必要性
仕様が変わるたびにテストコードも書き直す必要が出てきて、メンテナンスが大変になるケースも少なくありません。
記述量が増える
テストコードを取り入れると記述するコードの量は多くなります。
そのため、システム開発に必要なコードに加えて、テストコードを記述するためにも時間がかかり、開発の初期段階の負担は大きくなります。
4. テストコードの書き方
基本的な構造は「準備 → 実行 → 確認」の3ステップです。
① 準備（Arrange）：テストに必要なデータを用意する
② 実行（Act） ：テストしたい処理を実行する
③ 確認（Assert）：結果が期待通りかチェックする
実際のLaravelのテストコードで確認してみます。
public function test_ユーザーが正常にログインできる()
{
// ① 準備：テスト用のユーザーを作成する
$user = User::factory()->create();
// ② 実行：ログインを試みる
$response = $this->post('/login', [
'email' => $user->email,
'password' => 'password',
]);
// ③ 確認：ログインできたか（ダッシュボードに遷移するか）チェック
$this->assertAuthenticated();
$response->assertRedirect('/dashboard');
}
よく使うチェック（アサーション）
| コード | 意味 |
|---|---|
assertStatus(200) |
ページが正常に表示されるか |
assertRedirect('/dashboard') |
指定のページに遷移するか |
assertAuthenticated() |
ログインできているか |
assertGuest() |
ログアウトされているか |
assertDatabaseHas('users', [...]) |
データベースにデータが保存されているか |
assertSessionHasErrors('email') |
バリデーションエラーが出るか |
5. テスト駆動開発（TDD）とは
テスト駆動開発（TDD：Test-Driven Development）は、「テストを先に書き、そのテストを通すためだけに実装する」というサイクルを繰り返す開発手法です。
「テスト作成（赤）→ 実装（緑）→ リファクタリング（きれいにする）」の3ステップを短時間で回すことで、バグを未然に防ぎ、設計の良いコードを効率的に作ることができます。
TDDの3つのステップ（レッド・グリーン・リファクタ）
① Red（失敗するテストを書く）
実装したい機能のテストを先に書きます。最初は実装コードがないため、テストは当然「失敗（赤）」します。
目的：何を実装すべきか（仕様）を明確にする。
② Green（テストを通すコードを書く）
そのテストを通過させるためだけの、「最小限のコード」を書く。動けばOKです（緑）。
目的：テストを合格させる。
③ Refactor（コードを綺麗にする）
テストが通った状態（緑）を維持したまま、コードを読みやすく整理された形に書き直します。
目的：機能を変えずに、コードの品質を向上させる。
6. 学んで気づいたこと
今回テストコードについて学んで気づいたことがあります。
Laravelには最初から認証機能のテストコードが用意されていました。
今まで全く気づいていませんでしたが、テストコードについて学んだことで初めてその存在に気づくことができました。
また、自分で追加した機能（子ども管理・家族共有・予約管理など）のテストコードは自分で書く必要があることもわかりました。
テストコードは存在するだけでは意味がなく、自分が作った機能に合わせて自分で書いて初めて機能することを学びました。
まとめ
| 手動テスト | テストコード（自動テスト） | |
|---|---|---|
| 確認方法 | 画面を操作して目で確認 | コードを実行して自動確認 |
| スピード | 時間がかかる | 瞬時に全件実行 |
| 再現性 | 毎回手作業が必要 | 何度でも同じ条件で実行 |
| バグ発見 | 気づいた時だけ | 変更のたびに自動検出 |
前回の手動テストで発見したバグ（重複参加・全行エラーなど）は、テストコードがあれば修正後に再発していないか自動で確認できるようになります。
次回は実際にテストコードを書いてみて、気づいたことをまとめていきたいと思います。
参考文献
- Google検索「テストコードとは」「テスト駆動開発(TDD)とは」にて調査・学習