
Laravel Tdd
Practice red-green-refactor on Laravel features with Pest or PHPUnit, factories, and database strategies while targeting strong unit and feature coverage.
Overview
laravel-tdd is an agent skill most often used in Build (also Ship testing) that guides Laravel TDD with Pest or PHPUnit, layered tests, and 80%+ coverage habits.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill laravel-tddWhat is this skill?
- Red-Green-Refactor cycle: failing test, minimal pass, refactor with green suite
- 80%+ coverage target across unit and feature tests
- Three layers: unit (pure PHP), feature (HTTP/auth/validation), integration (DB/queue/externals)
- Database helpers: RefreshDatabase, DatabaseTransactions, DatabaseMigrations—with when-to-use guidance
- Pest preferred for new tests unless the repo already standardizes on PHPUnit
- 80%+ coverage target (unit + feature)
- 3 test layers (unit, feature, integration)
- 3 database testing strategies documented (RefreshDatabase, DatabaseTransactions, DatabaseMigrations)
Adoption & trust: 4.4k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are changing Laravel code without a failing test first, so regressions in models, policies, and HTTP behavior slip through manual checks.
Who is it for?
Indie Laravel SaaS or API projects adopting TDD for new endpoints, Eloquent behavior, jobs, and notifications.
Skip if: Non-PHP stacks, prototype spikes you intend to throw away without tests, or repos that forbid database-touching tests entirely.
When should I use this skill?
New Laravel features or endpoints, bug fixes or refactors, or when testing models, policies, jobs, and notifications.
What do I get? / Deliverables
You ship minimal implementations backed by unit, feature, and integration tests with an documented database testing strategy and sustained green runs.
- Failing-then-passing test files
- Documented layer choice per change
- Green suite toward 80%+ coverage goal
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
New Laravel endpoints and domain logic are authored during Build even when tests are written first. Laravel models, policies, jobs, and HTTP layers are backend work; TDD is the discipline applied there.
Where it fits
Drive a new JSON API endpoint from a failing Pest feature test through minimal controller and policy code.
Lock a bug fix with a regression feature test before refactoring duplicated validation rules.
Use green unit and feature suites as evidence during self-review before merge.
How it compares
Laravel-specific TDD playbook—not a generic Jest frontend testing skill or a CI-only lint pack.
Common Questions / FAQ
Who is laravel-tdd for?
Solo and small-team Laravel developers who want Pest or PHPUnit discipline on features, fixes, and refactors.
When should I use laravel-tdd?
While building new Laravel endpoints or domain code in Build, and during Ship when fixing bugs or hardening auth, validation, and policies with regression tests.
Is laravel-tdd safe to install?
The skill describes test and database patterns only; confirm trust via the Security Audits panel on this Prism page before agents run artisan or destructive test DB commands.
SKILL.md
READMESKILL.md - Laravel Tdd
# Laravel TDD Workflow Test-driven development for Laravel applications using PHPUnit and Pest with 80%+ coverage (unit + feature). ## When to Use - New features or endpoints in Laravel - Bug fixes or refactors - Testing Eloquent models, policies, jobs, and notifications - Prefer Pest for new tests unless the project already standardizes on PHPUnit ## How It Works ### Red-Green-Refactor Cycle 1) Write a failing test 2) Implement the minimal change to pass 3) Refactor while keeping tests green ### Test Layers - **Unit**: pure PHP classes, value objects, services - **Feature**: HTTP endpoints, auth, validation, policies - **Integration**: database + queue + external boundaries Choose layers based on scope: - Use **Unit** tests for pure business logic and services. - Use **Feature** tests for HTTP, auth, validation, and response shape. - Use **Integration** tests when validating DB/queues/external services together. ### Database Strategy - `RefreshDatabase` for most feature/integration tests (runs migrations once per test run, then wraps each test in a transaction when supported; in-memory databases may re-migrate per test) - `DatabaseTransactions` when the schema is already migrated and you only need per-test rollback - `DatabaseMigrations` when you need a full migrate/fresh for every test and can afford the cost Use `RefreshDatabase` as the default for tests that touch the database: for databases with transaction support, it runs migrations once per test run (via a static flag) and wraps each test in a transaction; for `:memory:` SQLite or connections without transactions, it migrates before each test. Use `DatabaseTransactions` when the schema is already migrated and you only need per-test rollbacks. ### Testing Framework Choice - Default to **Pest** for new tests when available. - Use **PHPUnit** only if the project already standardizes on it or requires PHPUnit-specific tooling. ## Examples ### PHPUnit Example ```php use App\Models\User; use Illuminate\Foundation\Testing\RefreshDatabase; use Tests\TestCase; final class ProjectControllerTest extends TestCase { use RefreshDatabase; public function test_owner_can_create_project(): void { $user = User::factory()->create(); $response = $this->actingAs($user)->postJson('/api/projects', [ 'name' => 'New Project', ]); $response->assertCreated(); $this->assertDatabaseHas('projects', ['name' => 'New Project']); } } ``` ### Feature Test Example (HTTP Layer) ```php use App\Models\Project; use App\Models\User; use Illuminate\Foundation\Testing\RefreshDatabase; use Tests\TestCase; final class ProjectIndexTest extends TestCase { use RefreshDatabase; public function test_projects_index_returns_paginated_results(): void { $user = User::factory()->create(); Project::factory()->count(3)->for($user)->create(); $response = $this->actingAs($user)->getJson('/api/projects'); $response->assertOk(); $response->assertJsonStructure(['success', 'data', 'error', 'meta']); } } ``` ### Pest Example ```php use App\Models\User; use Illuminate\Foundation\Testing\RefreshDatabase; use function Pest\Laravel\actingAs; use function Pest\Laravel\assertDatabaseHas; uses(RefreshDatabase::class); test('owner can create project', function () { $user = User::factory()->create(); $response = actingAs($user)->postJson('/api/projects', [ 'name' => 'New Project', ]); $response->assertCreated(); assertDatabaseHas('projects', ['name' => 'New Project']); }); ``` ### Feature Test Pest Example (HTTP Layer) ```php use App\Models\Project; use App\Models\User; use Illuminate\Foundation\Testing\RefreshDatabase; use function Pest\Laravel\actingAs; uses(RefreshDatabase::class); te