mcpField
L
laravel:tdd-with-pest

laravel:tdd-with-pest

github.com/jpcaparasTesting & quality157177 installsUpdated 17w ago
Repository

About laravel:tdd-with-pest

A Laravel testing skill for applying test-driven development with Pest or PHPUnit. It describes a fail-first, minimal implementation, and refactoring cycle with practical testing guidelines.

Key features

  1. 01Fail-first TDD cycle
  2. 02Pest or PHPUnit test runner
  3. 03Factories and seeders for test data
  4. 04Feature and unit test guidance
  5. 05Deterministic test practices

Use cases

  1. 01Start production changes with a failing test
  2. 02Test HTTP behavior and pure services
  3. 03Keep tests realistic and repeatable

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/jpcaparas/superpowers-laravel --skill laravel:tdd-with-pest

After installing, type/laravel:tdd-with-pestin Claude Code to confirm it loaded.

Details

From the project README

Laravel TDD (Pest/PHPUnit)

Write the test first. Watch it fail. Write minimal code to pass. Keep tests fast and realistic.

Test Runner

# Sail
sail artisan test --parallel

# Non-Sail
php artisan test --parallel

Prefer Pest (default in new Laravel apps). PHPUnit is fine if your project uses it.

RED – Write a failing test

  • Use model factories; avoid heavy mocking
  • Feature tests for HTTP/controllers; unit tests for pure services
  • Name tests by behavior

Example (feature):

it('rejects empty email on signup', function () {
    $response = $this->post('/register', [
        'name' => 'Alice',
        'email' => '',
        'password' => 'secret',
        'password_confirmation' => 'secret',
    ]);

    $response->assertSessionHasErrors('email');
});

Run and confirm it fails for the right reason.

GREEN – Minimal implementation

Write the simplest code to pass your failing test. No extras. No refactors.

REFACTOR – Clean up

Remove duplication, clarify names, extract small services. Keep tests green.

Guidelines

  • Every production change starts with a failing test
  • Watch failures; never skip the failing phase
  • Use factories/seeders for realistic data
  • Use DB transactions or refreshes in tests as needed
  • Keep tests deterministic; avoid sleeps in async flows

When stuck

  • If a test is hard to write, design is too coupled; extract a service or port
  • Prefer dependency injection; avoid static/global state

Comments

Markdown supported