対象バージョン: Laravel 13.x / PHP 8.3+(2026年時点のシリーズ基準)
一次ソース: Testing / HTTP Tests / Database Testing / Eloquent Factories
こんにちは。この記事では、Laravel 13.x で テストを実装する基本 を、現行の公式ドキュメントに沿って整理します。テストの作成と実行、アサーション、HTTP テスト、データベーステストまでを通します。Pest と PHPUnit のどちらを使うかはプロジェクト次第で、本記事はどちらか一方を必須にしません。まずは「Feature テストで HTTP と DB を安全に検証できる」状態を目指します。
この記事で分かること
- Laravel 13.x / PHP 8.3+ でのテスト配置と
make:test php artisan testによる実行- HTTP テスト(
get/assertStatus)と、認証・バリデーション・JSON の短い例 RefreshDatabaseとModel::factory()->create()による DB テスト
対象バージョン
本記事の前提は Laravel 13.x / PHP 8.3+ です。Laravel 13 は 2026年3月17日リリースの現行メジャーであり、サポート表上 PHP 8.3〜8.5 を対象とします(Release Notes)。フレームワーク本体も php: ^8.3 を要求します。
Laravel は Pest と PHPUnit の両方 のテストを out of the box でサポートします(Testing)。fresh な laravel/laravel 13.x の require-dev には phpunit/phpunit が含まれ、既定の tests は PHPUnit クラス例です(tests/Pest.php は最初からありません)。本記事のコード例は PHPUnit の Feature テストを主にします。Pest を使う場合も、同じ検証意図を短く置き換えられます。
旧手順にあったグローバル factory(App\Post::class) などは現行例から外し、RefreshDatabase と Model::factory() に置き換えます。
テストの作成
tests ディレクトリ
Laravel のテストは tests ディレクトリ配下に置きます。通常は次の2つです。
- Feature … アプリケーションを boot した機能テスト(HTTP・DB など)。入門の主経路
- Unit … アプリを boot しない単体テスト。DB などにはアクセスできない
まずは Feature から始めるのがおすすめです。
php artisan make:test
新しいテストは Artisan で生成します。
php artisan make:test PostTest
既定では tests/Feature/PostTest.php が作られます。Unit にしたい場合は --unit を付けます。
php artisan make:test PostTest --unit
スタブの種類を明示するときは --pest または --phpunit を使えます。既定スケルトンは PHPUnit 例が多い、という程度の差です。どちらか一方を必須にはしません。
テストの実行
実行は次のいずれかで行えます。本記事では php artisan test を主に使います(詳細なレポートが得られます)。
php artisan test
vendor/bin/phpunit や、Pest を入れている場合の vendor/bin/pest でも実行できます。
実行時、phpunit.xml の環境変数により APP_ENV=testing となり、session / cache は array ドライバに自動設定されます。laravel/laravel 13.x の phpunit.xml には Unit / Feature の suites と、testing 用の設定(例: sqlite :memory:)が既定であります。任意でプロジェクト直下に .env.testing を置くと、Pest / PHPUnit 実行時や --env=testing の Artisan で .env の代わりに使われます。
setUp / tearDown を独自に定義する場合は、必ず parent::setUp() / parent::tearDown() を呼んでください。
アサーション
テストメソッド内で、アサーションを使って期待どおりかを確かめます。PHPUnit の最小例です。
public function test_example(): void
{
$this->assertTrue(true);
}
Pest を使う場合は、同等の意図を expect(true)->toBeTrue(); のように書けます(本記事では以降 PHPUnit 例に統一します)。
HTTPテスト
Feature テストでは、アプリケーションへ HTTP リクエストを送り、レスポンスを検証できます。
public function test_post_index(): void
{
$response = $this->get('/posts');
$response->assertStatus(200);
}
認証ユーザーとしてのリクエスト(概要)
ログイン済みユーザーとしてリクエストするには actingAs($user) を使います。ゲストとして扱うには actingAsGuest() があります。
$user = User::factory()->create();
$response = $this->actingAs($user)->get('/dashboard');
$response->assertStatus(200);
バリデーション結果の検証(概要)
フォームやリクエストのバリデーション結果は、assertValid / assertInvalid などで確かめられます。セッションエラーや JSON のバリデーションエラー向けには、assertSessionHasErrors / assertJsonValidationErrors もあります。
$response = $this->post('/posts', [
'title' => '',
]);
$response->assertInvalid(['title']);
JSON / API レスポンス(概要)
API 向けには getJson / postJson などと、assertJson / assertJsonValidationErrors を組み合わせます。
$response = $this->postJson('/api/posts', [
'title' => 'Hello',
]);
$response->assertStatus(201)
->assertJson([
'title' => 'Hello',
]);
ルートやレスポンスの形は、自分のアプリの実装に合わせて読み替えてください。
データベーステスト
DB を触るテストでは、テスト間でデータが残らないようにします。公式の主経路は Illuminate\Foundation\Testing\RefreshDatabase トレイトです。スキーマが最新なら、各テストをトランザクション内で実行し、終了後に状態を戻します。
レコードの用意は、現行では Model::factory()->create() を使います。モデルに HasFactory を付け、Database\Factories\{Model}Factory の規約(または UseFactory)で ::factory() が解決されます。ファクトリクラスは次で生成できます。
php artisan make:factory PostFactory
注意: 古い記事や資料にあったグローバル factory(App\Post::class) は、現行 Laravel 13.x のヘルパーにはありません。学習用の主例にしないでください。
<?php
namespace Tests\Feature;
use App\Models\Post;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;
class PostDatabaseTest extends TestCase
{
use RefreshDatabase;
public function test_post_can_be_created(): void
{
$post = Post::factory()->create();
$this->assertDatabaseHas('posts', [
'title' => $post->title,
]);
}
}
assertDatabaseHas で、指定テーブルに条件に合う行があることを確認できます。モデル名空間はプロジェクトに合わせて App\Models\Post を前提にしています。
最後に
以上が、Laravel 13.x でテストを実装する基本です。作成(make:test)→ 実行(php artisan test)→ HTTP(get + assertStatus)→ DB(RefreshDatabase + Model::factory())までを、まず Feature で通せるようにしておくと、以降の機能追加が安全になります。
モックやフェイク、ブラウザテスト(Dusk)、CI の並列実行などは、公式の Mocking ドキュメントなどを必要になったタイミングで足していくとよいです。本記事では入門範囲に絞り、独立したモック章は設けていません。