第11回: テスト戦略（Feature/Pest） — Unitテストだけが増えても、できるアプリは守れません

(Updated: )
1 min read

章: 第5章: テストと保守性

「Unitテストが全部緑なのにリファクタ後に本番でバグが起きた」――これは、実装詳細をテストしていて、ユーザーが実際に使う流れ をテストしていなかったために起きます。

LaravelのFeatureテストは「ブラウザから見た持ろ入れからレスポンスまで」を一撬で検証します。Pestを組み合わせることで、恋ろしい楽しいテストコード を書くことができます。

なぜFeatureテストが重要なのか

Unitテスト中心のテスト戦略には次の落とし穴があります。

  • クラスの内部詳細に依存するため、リファクタに弱い
  • ラウティング・ミドルウェア・認証の組み合わせがテストされない
  • 「チェックボックスにチェックしただけ」のテストが増える

チェックポイント: Featureテスト ≈ E2E、Unitテスト ≈ 関数単体。この2層構造を意識するだけで、テスト戦略が大きく変わります。

Feature vs Unit — 使い分けの基準

観点 Unitテスト Featureテスト
テスト対象 単一クラス/関数 HTTPリクエスト全体
リファクタ耐性 低い（実装変更で壊れる） 高い（定義した仕様を守る）
モック導入 必要 不要（実際のDB・ウォーカーを使う）
価値 ロジックの正確性 機能の動作保証

実装例（Pestで書く）


<?php
// tests/Feature/Post/CreatePostTest.php
it('ユーザーが記事を投稿できる', function () {
    $user = User::factory()->create();

    $response = $this->actingAs($user)->post('/posts', [
        'title' => 'Laravel上級編',
        'body' => '本文',
    ]);

    $response->assertRedirect('/posts');
    $this->assertDatabaseHas('posts', ['title' => 'Laravel上級編']);
});

まとめ & 次のステップ

  • Featureテストで「ユーザーが実際に使うフロー」を保護するのがテスト戦略の基本
  • Pestの it() 構文で日本語テスト名が書け、仕様書とテストが一致する
  • actingAs() で認証・未認証の認可テストが簡潔に書ける
  • Unitテストはアルゴリズムの正確性検証、Featureテストはアプリの機能保証――両方が必要

次回は 第12回: Octane導入と運用注意点 で、常駐アプリケーションによる高スループット运用の要点を学びます。

Related Articles