「修正したらどこか壊れそう…」をなくす。LaravelのFeatureテスト入門

# 1. 依存パッケージのインストール
$ composer install

# 2. 環境設定ファイルのコピーとアプリケーションキーの生成
$ cp .env.example .env
$ php artisan key:generate

# 3. テスト用データベースファイルの作成（SQLiteを使用する場合）
$ touch database/testing.sqlite

# 4. テスト環境の.env設定を確認
# .env ファイル内に以下の設定がされていることを確認してください
# DB_CONNECTION=sqlite
# DB_DATABASE=database/testing.sqlite

# 5. テスト用データベースにマイグレーションを実行
# Laravelの Feature テストは実行時に自動でマイグレーションを実行するため、通常はこの手順は不要です。
# ただし、手動でテスト環境を確認したい場合に実行します。
# ※ Laravelでは、.env.testing ファイルを用意することでテスト環境の設定を自動化できます。
$ php artisan migrate --env=testing

✍️ まず書いてみる：Featureテストの実践（フォーム送信機能の検証）

Featureテストの概念を理解したところで、実際に最も頻繁に行うテストの一つである「フォーム送信」のテストを書いてみましょう。このテストは、ユーザーがフォームにデータを入力し、送信ボタンを押したときに、サーバー側で処理が実行され、データベースが更新され、適切なリダイレクトが行われるという一連の機能全体を検証します。

テストファイルの作成と構造の解説

Artisanコマンドを使って、新しいテストファイルを作成します。

$ php artisan make:test PostCreationTest --type=feature

作成された tests/Feature/PostCreationTest.php ファイルに、以下の投稿ロジックのテストを記述します。

ファイル例：tests/Feature/PostCreationTest.php

<?php
namespace Tests\Feature;

use Tests\TestCase;
use Illuminate\Foundation\Testing\RefreshDatabase;
use App\Models\Post; // 必要に応じてModelをインポート

class PostCreationTest extends TestCase {

    // 💡 このトレイトが、テスト実行ごとにデータベースをクリーンな状態に戻します
    use RefreshDatabase; 

    /
     * @test
     * ゲストユーザーが記事投稿フォームを正常に送信できることを確認
     */
    public function test_guest_can_submit_post_and_is_redirected() {
        // 1. フォーム送信の実行
        // $this−>post(URL, [データ]) を使い、POSTリクエストを模倣します
        $response = $this->post('/posts', [
            'title' => 'はじめてのテスト投稿',
            'body' => 'Featureテストで投稿の動作（CRUDのC）を確認します。',
        ]);

        // 2. HTTPステータスの検証
        // 成功時のリダイレクト（通常は302）を確認
        $response->assertStatus(302); 

        // 3. リダイレクト先の検証
        // 期待通りのページへ遷移したかを確認
        $response->assertRedirect('/posts'); 

        // 4. データベースの状態検証
        // 最も重要な検証：データベースに期待したデータが正しく挿入されたかを確認
        $this->assertDatabaseHas('posts', [
            'title' => 'はじめてのテスト投稿',
            'body' => 'テストで投稿の動作を確認します。', // 部分一致でも検証可能
        ]);

        // 補足: データベースにデータが1件増えたことも検証可能
        $this->assertCount(1, Post::all());
    }
}

テストコードの重要ポイント解説

• use RefreshDatabase;

  このトレイトを使用すると、各テストメソッドが実行されるたびにデータベースのテーブルが作り直され、完全に空の状態からテストが開始されます。これにより、前のテストデータが次のテストに影響を与える「テストの汚染」を防ぎ、テストの信頼性を高めることができます。

• $this−>post(‘/posts’, [data])

  Featureテストの根幹です。ブラウザから /posts URLに対して POST リクエストを送信する操作を完全に模倣します。第二引数の配列が、フォームから送信されたデータ（RequestオブジェクトとしてControllerに渡される）となります。

• $response−>assert… アサーション群

  Controllerの処理が完了し、返された $response オブジェクトに対して検証を行います。
  assertStatus(302): HTTPステータスコードが期待通りか。
  assertRedirect(‘/posts’): 特定のURLへリダイレクトされたか。
  他にも assertSee(‘テキスト’) や assertForbidden() など多数あります。

• $this−>assertDatabaseHas(‘table’, [data])

  Controllerが実行した後のデータベースの状態を検証します。指定したテーブル（ここでは posts）に、指定したキーと値のペアを持つ行が一つ以上存在するかを確認します。

対応するController側のロジック

テストが想定する Controller 側のロジックは、以下のような一般的な投稿処理となります。（validateでバリデーションを行い、Post::createでデータベースに保存し、リダイレクトしています。）

<?php

// App\Http\Controllers\PostController.php
public function store(Request $request) {
    // 1. バリデーション
    $validated = $request->validate([
        'title' => 'required|max:255',
        'body' => 'required',
    ]);

    // 2. データベースへの保存
    Post::create($validated);

    // 3. リダイレクト
    return redirect('/posts');
}

この一連の流れをテストコードが自動で検証することで、この store メソッドを将来修正しても、壊れていないかを瞬時に確認できるようになるのです。

🔒 認証が絡む場合のテスト：ログイン済みユーザーでの投稿検証

多くのアプリケーション機能（記事の投稿、設定の変更、商品購入など）は、ユーザーがログインしていることを前提としています。Featureテストでこれらの機能を検証する場合、実際にログインフォームからログイン操作を行う必要はなく、Laravelが提供するヘルパーメソッドを使って、プログラム的に「認証済み状態」を模擬（モック）することができます。

認証済みユーザーを模擬する方法（actingAsの利用）

Laravelのテストでログイン済みユーザーとして振る舞うには、$this−>actingAs($user) メソッドを使用します。このメソッドは、指定したユーザーオブジェクト（$user）を使って、アプリケーションのセッションに認証情報を設定します。

ファイル例：tests/Feature/AuthPostTest.php

<?php

namespace Tests\Feature;

use Tests\TestCase;
use Illuminate\Foundation\Testing\RefreshDatabase;
use App\Models\User; // 認証に必要なユーザーモデルをインポート

class AuthPostTest extends TestCase {
    // テスト実行ごとにDBをリセット
    use RefreshDatabase; 

    /**
     * @test
     * 認証済みユーザーが記事投稿フォームを正常に送信できることを確認
     */
    public function test_authenticated_user_can_create_post() {
        // 1. ユーザーの準備 (Arrange)
        // 💡 User::factory()−>create() を使用し
        //    テストに必要なダミーユーザーをDBに作成します。
        $user = User::factory()->create();

        // 2. 認証状態の模倣とフォーム送信の実行 (Act)
        // $this−>actingAs($user) をチェーンメソッドとして呼び出し、
        // その後の POST リクエストをこのユーザーが実行したかのように振る舞わせます。
        $response = $this->actingAs($user)->post('/posts', [
            'title' => '認証済みの投稿テスト',
            'body' => 'ユーザーがログインしている場合の正常系テストです。',
            'user_id' => $user->id, // 投稿にユーザーIDが必要な場合
        ]);

        // 3. 検証 (Assert)
        // 成功時のリダイレクトを確認
        $response->assertStatus(302); 

        // データベースに投稿が正しく保存され、所有者IDも正しく紐付いているかを確認
        $this->assertDatabaseHas('posts', [
            'title' => '認証済みの投稿テスト',
            'user_id' => $user->id,
        ]);
    }
}

テストコードの重要ポイント解説

• User::factory()−>create();

  テストで利用するユーザーデータを簡単に用意するために、モデルファクトリ（Model Factory）を利用します。これにより、必要なダミーデータ（名前、メールアドレス、パスワードなど）が自動生成され、テスト専用のデータベースに挿入されます。テスト駆動開発において必須の準備となります。

• $this−>actingAs($user)

  このメソッドを一度呼び出すだけで、以降の get(), post(), put(), delete() といったHTTPリクエストが、すべてこの $user がログインした状態として実行されます。これにより、Controller側で auth()−>check() や @auth ディレクティブを使った認証チェックがパスするようになります。

• コントローラ側の影響

  Controller内で auth()−>id() や auth()−>user() を呼び出すと、ファクトリで作成された $user のIDやオブジェクトが正しく取得できるようになります。

さらに応用として、権限を持たないユーザーが管理画面にアクセスしようとしたときに、$response−>assertForbidden() や $response−>assertRedirect(‘/login’) が返されるかを検証するテストも、この actingAs を使って簡単に実現できます。

🌐 外部サービスを使う機能のテスト：Laravelにおける「モック（Mock）」の強力な使い方

アプリケーションが外部サービス（サードパーティAPI、メールサーバー、決済ゲートウェイ、S3などのクラウドストレージ）と連携する機能を持つ場合、Featureテストでそれらの連携を検証する際に、いくつか大きな問題が生じます。

問題点:

1. 速度の低下: 外部サービスとの通信は、ローカル処理よりもはるかに時間がかかり、テストスイート全体の実行速度が極端に遅くなります。
2. 不安定性: 外部サービス側の障害やネットワークエラー、認証情報の期限切れなどにより、アプリケーションのコード自体は正しくてもテストが失敗する「不安定なテスト（Flaky Test）」になります。
3. 費用・データの汚染: 決済APIのテストでは実際の費用が発生したり、メール送信テストでは関係者に迷惑メールが届いたりする副作用が生じます。

これらの問題を解決するために、LaravelはFacade（ファサード）を通じてアクセスされる外部依存を、「モック（Mock）」や「フェイク（Fake）」と呼ばれる機能で「偽物」に置き換える仕組みを提供しています。

実践例：メール送信機能のモック化（Mail::fake()）

ユーザー登録が完了した際にウェルカムメールが送信される機能をテストする場合を考えます。Mail::fake()を使用することで、実際にSMTPサーバーへの接続は行わず、「WelcomeMailが送信される処理が呼び出された」という事実だけを検証できます。

ファイル例：tests/Feature/MailTest.php

<?php

namespace Tests\Feature;

use Tests\TestCase;
use Illuminate\Support\Facades\Mail; // 💡 Facadeをインポート
use Illuminate\Foundation\Testing\RefreshDatabase;
use App\Mail\WelcomeMail; // 検証対象のMailableクラスをインポート

class MailTest extends TestCase {
    use RefreshDatabase;

    /
     * @test
     * ユーザー登録後にウェルカムメールが正しく送信されることを確認
     */
    public function test_welcome_mail_sent_on_registration() {
        // 1. メール機能をモック化（Fake）
        // この呼び出し以降、Mail Facadeを通じた全てのメール送信は実際には行われず、記録されるだけになります。
        Mail::fake(); 

        // 2. ユーザー登録の実行 (Controllerでメール送信ロジックが実行される)
        $response = $this->post('/register', [
            'name' => 'テスト 太郎',
            'email' => '[email protected]',
            'password' => 'password',
            'password_confirmation' => 'password',
        ]);

        // 3. データベースへの登録とリダイレクトの確認（追加の検証）
        $response->assertRedirect('/home'); 

        // 4. 検証（Assert）
        // 💡 Mail::assertSent() を使い、WelcomeMail::class が一度送信されたことを検証します。
        // 実際にネットワーク通信は発生していません。
        Mail::assertSent(WelcomeMail::class);

        // 補足: 複数回送信されていないことや、特定のユーザーに送信されたかも検証可能
        // Mail::assertNotSent(AdminNotificationMail::class);
        // Mail::assertSentTo('[email protected]', WelcomeMail::class);
    }
}

モック化の適用範囲：HTTPクライアント（外部API）

このモック化の仕組みはメール送信だけに留まりません。外部APIとの通信を行うHTTPクライアント（Illuminate\Support\Facades\Http）でも同様に使えます。

• Http::fake() を使用することで、特定の外部URLへのリクエストに対して、あらかじめ定義した応答（JSONデータなど）を返すように設定できます。
• これにより、ネットワークの速度や外部APIの状態に依存することなく、「APIからエラーが返ってきた場合の処理」や「正常なデータが返ってきた場合のDB更新」といったアプリケーションのロジックだけを高速かつ安定して検証できます。

結論として、Featureテストにおける外部依存のモック化は、テストの実行速度と安定性を確保するために不可欠な手法です。これにより、アプリケーションの中核となるロジックの品質保証に集中できるようになります。

❌ よくある失敗とその直し方（初心者が陥りやすいポイント）

Featureテストは開発の強力な味方ですが、実際に書き始めると、環境設定や外部依存の扱いで初心者が最初に躓きやすいポイントがいくつかあります。ここでは、代表的な失敗の原因と、それを解決するための具体的な対処法をまとめます。

1. 💾 DBがコケる（マイグレーションが反映されない・データが残ってしまう）

原因: テスト環境のデータベース設定が本番・開発環境の設定と混ざってしまっている、あるいは、テスト実行前にデータベース構造（テーブル）が正しく構築されていないことにあります。

対処法:

• ✅ RefreshDatabase トレイトの徹底利用: 各テストメソッドでデータベースをクリーンにする use RefreshDatabase; トレイトを必ず利用します。これにより、テスト実行時に自動でマイグレーションが実行され、テスト終了後にロールバックされるため、データ汚染を防げます。
• ✅ テスト用DB接続の明示:
  • SQLiteの利用: 最も手軽なのは、phpunit.xml や .env.testing でDB\_CONNECTIONを sqlite に、DB\_DATABASEを :memory: （インメモリDB）またはファイルパス（database/testing.sqliteなど）に設定することです。インメモリDBは非常に高速です。
  • 専用のMySQL DBの利用: 接続設定を DB_DATABASE=testing_db のように明確に分け、テスト実行で本番DBを絶対に触らないようにします。

2. 🛡️ CSRFやミドルウェアで 401/419/403 が返る

原因: Featureテストはブラウザ操作を模擬しますが、標準ではセッション情報やCSRFトークンを持っていません。また、認証されていないにもかかわらず、特定のミドルウェア（auth、canなど）を通過しようとしています。

対処法:

• ✅ 認証テスト: ログインが必要な機能では、必ず $this−>actingAs($user) を使ってユーザーを認証済み状態にしてからリクエストを送ります。
• ✅ トークンを無視: POSTリクエスト時に、CSRF（419エラーの原因）チェックを回避するため、$this−>postJson() や $this−>withHeaders() メソッドを使用します（APIテストの場合）。通常のHTMLフォームテストではLaravelが賢く処理してくれますが、APIの場合は明示的にヘッダ設定が必要です。
• ✅ ミドルウェアの無効化（最終手段）: 特定のテストケースでのみ、ミドルウェアの検証が不要な場合、withoutMiddleware() を使って一時的にミドルウェアを無効化できます。ただし、これはミドルウェアの機能自体をテストしたい場合に問題となるため、慎重に利用してください。

3. 🖼️ ファイルアップロードテストが失敗する

原因: ファイルアップロードのテストを実行しても、Laravelの storage 領域が準備されていないか、実際のディスクに書き込みが行われようとして失敗しています。

対処法:

• ✅ Storage::fake() でストレージをモック化: テストメソッドの冒頭で \Storage::fake(‘public’); のように呼び出します。これにより、実際のディスクへの書き込みは行われず、メモリ上の仮想ストレージにファイルが保存されたかのように振る舞います。
• ✅ アップロードファイルの準備: テスト用のダミーファイルは UploadedFile::fake() を使って作成します。

  $file = UploadedFile::fake()−>image('avatar.jpg');
  $this−>post('/profile', ['photo' => $file]);

• ✅ 保存の検証: 処理後、ファイルが正しく保存されたことを \Storage::disk(‘public’)−>assertExists(‘ファイル名’); で確認します。

4. 🐌 テストスイート全体の実行が遅い

原因: 個々のテストは速くても、テストスイート全体で重い外部呼び出しや非効率なデータ準備が何度も繰り返されていることが原因です。

対処法:

• ✅ 外部依存のモック化を徹底: Mail::fake() や Http::fake() を利用し、メール送信や外部API通信といったネットワークI/Oを完全にスキップさせます。これがテスト高速化の最も大きな鍵です。
• ✅ データベースの最適化: SQLiteのインメモリDB（DB\_DATABASE=:memory:）を使用します。ファイルI/Oが発生しないため、マイグレーションとロールバックが劇的に高速になります。
• ✅ シード処理の回避: RefreshDatabase トレイトはマイグレーションのみを実行します。テストに必要な最小限のデータは Model::factory() でテストメソッド内で直接作成し、php artisan db:seed のような重い処理を避けます。

🛠️ 実務で役立つテスト設計のコツ：保守性の高いテストコードを書くために

Featureテストは、単にコードが動くことを確認するだけでなく、将来のデグレード（機能破壊）を防ぐ「資産」となるべきです。そのためには、テストコード自体が読みやすく、修正しやすく、「壊れたときに原因を特定しやすい」ように設計されている必要があります。

特に初心者がテストを書く際に意識すべき、保守性の高いテスト設計のルールを解説します。

テスト設計の4つの黄金ルール

• 1️⃣ 1テスト = 1検証 (Single Assertion Principle)

  一つのテストメソッドでは、 アプリケーションの一つの特定の振る舞い（振る舞い全体ではなく）のみを検証するようにします。

  ❌ 悪い例: 記事投稿テストで、「DB保存」「メール送信」「リダイレクト」「キャッシュクリア」の全てを一つのメソッドで検証する。

  ✅ 良い例: 投稿テストを「投稿が成功し、DBに保存されたことの検証」、「投稿後にウェルカムメールが送信されたことの検証」、「不正な値で投稿したときのエラーメッセージの検証」など、目的ごとにメソッドを分けて記述します。テストが失敗した際、何が壊れたのかがメソッド名を見ただけで即座に判明します。

• 2️⃣ Arrange-Act-Assert (AAA) の明確化

  テストメソッド内を、以下の3つのステップに明確に分けて記述します。これにより、テストコードの構造が統一され、非常に読みやすくなります。

  • Arrange（準備）: テストに必要な初期状態（ユーザー作成、ダミーデータの設定、モックの設定など）を整える。
  • Act（実行）: 検証したい実際の操作（$this−>post(‘/posts’, data) など）を実行する。
  • Assert（検証）: 実行結果（レスポンスステータス、DBの状態など）が期待通りかを確認する。

• 3️⃣ Factory でデータを作成し、setUp の重複を避ける

  テストデータ（ユーザー、記事、コメントなど）を手書きで配列として用意するのではなく、Laravelのモデルファクトリ (Model Factory) を利用します。

  User::factory()->create(); のように記述することで、テストに必要な最小限のコードで複雑なデータ構造を生成できます。これにより、テストコードがシンプルになり、データモデルに変更があってもファクトリだけを直せば済むため、保守性が向上します。

• 4️⃣ モックは必要最小限に（外部依存のみ）

  外部に依存するもの（メール、外部API、S3など）は、前述のように Mail::fake() や Http::fake() で必ずモック化します。しかし、アプリケーションの内部のクラス（UserServiceなど）のメソッド呼び出しをモック化するのは、Featureテストでは避けるべきです。

  理由: Featureテストの目的は、「複数のコンポーネントが連携して動いた結果」を検証することだからです。内部のコンポーネントまでモックにしてしまうと、その連携部分が壊れてもテストでは検知できなくなります。

特に初心者がやりがちなのが、「複数の振る舞いを一つのテストで検証する」ことです。これを避け、「1テスト = 1検証」を徹底するだけで、テストコードは劇的に改善し、開発スピードを落とさない「動くドキュメント」として機能するようになります。

🤖 CI/CDでの運用と Feature テストの自動化：開発フローに組み込む

ローカル環境でFeatureテストを書き、無事にグリーン（成功）になったら、そのテストを継続的インテグレーション（CI）環境で自動実行するように設定することが、テスト駆動開発（TDD）の最大の価値を引き出す鍵となります。

CIツール（GitHub Actions、GitLab CI、Jenkinsなど）を利用することで、開発者が新しいコードをプッシュしたり、プルリクエスト（PR）を作成したりするたびに、全てのテストが自動で実行されます。これにより、意図しない破壊（デグレード）が本番環境にデプロイされることを未然に防ぐ強力なゲートウェイとなります。

CI設定における重要ポイント

CI環境はローカル環境とは異なるため、テストが正しく動作するようにいくつかの準備が必要です。

• 📥 依存関係のインストール

  composer install を実行し、プロジェクトが必要とする全てのライブラリ（特に phpunit やその関連パッケージ）がCI環境にインストールされていることを確認します。通常は –no-dev オプションを外すか、テストに必要な –dev パッケージを含めてインストールします。

• ⚙️ 環境変数とデータベースの構成

  ローカルと同様に、テスト実行用のデータベース接続情報（.env.testing またはCIツールのSecrets）を正しく設定し、テスト実行前にマイグレーションを実行してデータベースのスキーマを準備する必要があります。このとき、本番環境のDBを誤って触らないように、テスト用の接続設定（SQLiteの :memory: や専用のテストDB）を明確に指定します。

• 🧹 キャッシュ/コンパイルアーティファクトのクリア

  Laravelの環境がクリーンであることを保証するため、config:clear や route:clear などのArtisanコマンドを実行し、古いキャッシュが原因でテストが失敗するのを防ぎます。

• ⚡️ テストの並列実行（大規模プロジェクト向け）

  プロジェクトの規模が大きくなり、テストスイートの実行時間が5分、10分と長くなってきた場合、CIツールやPHPUnitの機能を使ってテストを複数のジョブに分割し、並列で実行することで、トータルの実行時間を大幅に短縮できます。

実践例：GitHub Actions ワークフロー（Featureテスト自動実行）

GitHubを利用している場合、以下のシンプルなワークフローファイル（通常 .github/workflows/tests.yml に配置）を追加するだけで、PR時やマージ時に自動でテストを実行できます。

name: Run Laravel Tests

on:
  push:
    branches: [ "main", "develop" ] # mainとdevelopへのpushで実行
  pull_request: # プルリクエスト作成時、更新時に実行

jobs:
  tests:
    runs-on: ubuntu-latest # 実行環境のOS指定

    steps:
      - name: Checkout code
        uses: actions/checkout@v4 # 💡 コードをチェックアウト

      - name: Setup PHP Environment
        # PHPのバージョンを設定し、必要な拡張をインストール
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2' # 使用しているバージョンに合わせる
          extensions: imagick, mbstring, pdo, pdo_sqlite 

      - name: Install dependencies
        run: composer install --no-progress --no-suggest --prefer-dist

      - name: Prepare Test DB (Using SQLite)
        run: |
          touch database/testing.sqlite # 💡 テスト用SQLiteファイルを作成
          # env=testingを適用し、テスト用DBに対してマイグレーション実行
          php artisan migrate --env=testing --force 

      - name: Run PHPUnit Tests
        # phpunitの実行
        run: vendor/bin/phpunit --configuration phpunit.xml

CIで毎回テストが通る（PRに✅マークが付く）ことは、コードの品質に対するチーム全体の信頼感を高め、開発プロセス全体の安定性を保証します。Featureテストは、ローカルで書き、CIで育てることで真価を発揮するのです。

✅ よく使う Feature テスト用アサーション一覧（実務で必須のチートシート）

Featureテストで検証（Assert）を行うために、Laravelは非常に多くの便利なアサーションメソッドを提供しています。これらは、HTTPレスポンスオブジェクト（$response）に対して呼び出すものと、データベースやメールなどのLaravelのFacade（ファサード）に対して呼び出すものに大別されます。

特に利用頻度が高く、 Feature テストの骨格となるアサーションを厳選して覚えておきましょう。

カテゴリ	アサーション	用途と実例
HTTPレスポンス	$response−>assertStatus(200) / assertStatus(404)	レスポンスのHTTPステータスコード（200 OK, 404 Not Found, 403 Forbiddenなど）が期待値と一致するかを確認します。
リダイレクト	$response−>assertRedirect(‘/home’)	処理後にリダイレクトが行われたこと、およびリダイレクト先URLが正しいことを確認します。
画面表示	$response−>assertSee(‘ようこそ’)	レスポンスボディ（HTMLなど）に期待する文字列が含まれているかを確認します。
DB検証 (存在)	$this−>assertDatabaseHas(‘users’, [‘email’ => ‘[email protected]’])	指定したテーブルに、特定の条件を満たす行が確かに挿入された（または更新された）ことを検証します。
DB検証 (非存在)	$this−>assertDatabaseMissing(‘posts’, [‘id’ => 99])	指定したテーブルに、特定の条件の行が存在していないことを確認します（削除機能の検証などに使用）。
認証	$this−>assertAuthenticated() / assertGuest()	テスト実行後、ユーザーがログイン状態にあるか（またはログアウト状態にあるか）を検証します。
メール	Mail::assertSent(WelcomeMail::class)	Mail::fake() を使用している場合に、特定のMailableクラスが送信キューに入ったか（送信処理が実行されたか）を確認します。

これらのアサーションを組み合わせることで、「ログインが成功したら、200が返り、データベースにログイン情報が記録され、ウェルカムメールが送られる」という一連の機能全体をコードで保証できるようになります。

🚨 実践 Tips：テストが壊れたときの調査フロー（デバッグ戦略）

テストが失敗（赤く）なったときが、テストが最も役に立っている瞬間です。しかし、どこで何が壊れたのかが分からないと、不安になります。慌てずに原因を切り分けるための体系的な調査フローを身につけましょう。

1. 1. 🧪 失敗したテストだけを単独で実行し、ログを精査する

   最も重要な最初のステップです。テスト全体ではなく、失敗したメソッドやクラスだけを単独で実行します。

   # 失敗したクラスだけを実行
   $ vendor/bin/phpunit tests/Feature/PostCreationTest.php 
   
   # 失敗したメソッドだけを実行
   $ vendor/bin/phpunit --filter test_guest_can_submit_post

   単独実行で失敗が再現すれば、原因はそこにあります。出力されたエラーメッセージとスタックトレースから、どのアサーションが期待値と異なったかを確認します。

2. 2. 🧐 どのアサーションで落ちているかを特定する

   失敗した場所が assertStatus(200) の手前か、assertDatabaseHas() の手前かを確認します。これにより、問題が「Controllerにたどり着く前」か「Controllerの処理中」か、あるいは「Controllerの処理後のDBの状態」にあるのかを切り分けられます。

3. 3. 🏭 関連するデータ準備（Factory/Seeder）やミドルウェアの影響を疑う

   テストが失敗したのが認証後や特定のユーザー操作後の場合、準備フェーズ（Arrange）に問題がないか確認します。

   • Factory: 作成したユーザーの権限（ロール）が足りているか？
   • ミドルウェア: 意図せずミドルウェア（Throttleなど）がテストをブロックしていないか？
   • CSRF: POSTリクエストがCSRFトークン不足（419）になっていないか？（$this−>post() の代わりに $this−>postJson() を試すなど）

4. 4. 🔍 DBの状態や変数の値を dump/Log で確認する

   テストコード内に一時的に dump() や logger()−>info() を差し込み、Controllerに送られたデータや、DBに保存されたデータが期待通りかを確認します。 * 例: dd(Post::all()−>toArray()); をアサーションの前に差し込み、テストを止め、DBの中身を直接確認する。 * 注意: テスト用なので問題ありませんが、デバッグ出力が終わったら、必ずこれらのデバッグコードを削除するのを忘れないようにしましょう。

テストログは、バグ調査における最も重要な情報源です。この調査フローを習慣化することで、どんな複雑なバグでも冷静に、短時間で原因を特定できるようになります。

📚 テストのスキルを次のレベルへ

Featureテストは一度身につければ、あなたのエンジニアとしての市場価値を確実に高めます。さらに学習を深めたい方向けに、私が頻繁に参照する公式ドキュメントと重要概念をリストアップします。

• 📘 Laravel 公式ドキュメントの Testing セクション

  Featureテストだけでなく、Unitテスト、Browserテスト、コンソールテストなど、Laravelのテスト機能の全貌が網羅されています。新しいアサーションを探す際の最高の資料です。

• 🏭 モデルファクトリ（Model Factory）と State の使い方

  テストデータ作成の自動化は時間節約の鍵です。ファクトリの state 機能を使って「管理者ユーザー」「未承認記事」など、特定の状態を持つデータを瞬時に作成する方法をマスターしましょう。

• 📧 モック機能の応用（Mail::fake() や Http::fake()）

  モックは、レスポンス内容を細かく指定したり、複数のリクエストに対する応答を切り替えたりすることができます。これにより、「外部APIがエラーを返した場合」といったネガティブケースのテストも簡単に実現できます。

• ✅ CIの基本設定（GitHub Actions等）

  テスト実行の次のステップは自動化です。GitHub Actionsの yaml ワークフローの書き方を学び、ローカルのテストをチームの共通資産に変えましょう。

テストは早ければ数時間で効果が見えます。今日書いた1本のテストが、明日あなたの不安を取り除き、高速で安全な開発を約束します。