Source profileQuality 73/100

affaan-m/ECC/docs/es/skills/laravel-tdd/SKILL.md

laravel-tdd

Desarrollo guiado por pruebas para Laravel con PHPUnit y Pest, factories, pruebas de base de datos, fakes y objetivos de cobertura.

Source repository stars
234,327
Declared platforms
0
Static risk flags
0
Last source update
2026-07-27
Source checked
2026-07-28

Decision brief

What it does—and where it fits

Desarrollo guiado por pruebas para aplicaciones Laravel usando PHPUnit y Pest con 80%+ de cobertura (unit + feature).

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/affaan-m/ECC --skill "docs/es/skills/laravel-tdd"
    Safe inspection promptEditorial

    Inspect the Agent Skill "laravel-tdd" from https://github.com/affaan-m/ECC/blob/4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38/docs/es/skills/laravel-tdd/SKILL.md at commit 4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

      Cuándo Usar

      Nuevas funcionalidades o endpoints en Laravel

      Nuevas funcionalidades o endpoints en LaravelCorrecciones de bugs o refactorizacionesProbar modelos Eloquent, policies, jobs y notifications
    2. 02

      Cómo Funciona

      1) Escribir una prueba fallida 2) Implementar el cambio mínimo para que pase 3) Refactorizar manteniendo las pruebas en verde

      Escribir una prueba fallidaImplementar el cambio mínimo para que paseRefactorizar manteniendo las pruebas en verde
    3. 03

      Ciclo Rojo-Verde-Refactorizar

      1) Escribir una prueba fallida 2) Implementar el cambio mínimo para que pase 3) Refactorizar manteniendo las pruebas en verde

      Escribir una prueba fallidaImplementar el cambio mínimo para que paseRefactorizar manteniendo las pruebas en verde
    4. 04

      Capas de Prueba

      Elegir capas según el alcance:

      Unit: clases PHP puras, objetos de valor, serviciosFeature: endpoints HTTP, autenticación, validación, policiesIntegration: base de datos + colas + límites externos
    5. 05

      Estrategia de Base de Datos

      Usar RefreshDatabase como predeterminado para pruebas que tocan la base de datos: para bases de datos con soporte de transacciones, ejecuta las migraciones una vez por ejecución de prueba (mediante un flag estático) y envuelve cada prueba en una transacción; para SQLite :memory:…

      RefreshDatabase para la mayoría de pruebas feature/integration (ejecuta migraciones una vez por ejecución de prueba, luego envuelve cada prueba en una transacción cuando está soportado; las bases de datos en memoria pue…DatabaseTransactions cuando el esquema ya está migrado y solo se necesita rollback por pruebaDatabaseMigrations cuando se necesita un migrate/fresh completo para cada prueba y se puede asumir el costo

    Permission review

    Static risk signals and limitations

    No configured static risk pattern was detected

    This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score73/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars234,327SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    affaan-m/ECC
    Skill path
    docs/es/skills/laravel-tdd/SKILL.md
    Commit
    4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38
    License
    MIT
    Collected
    2026-07-28
    Default branch
    main
    View the original SKILL.md

    Flujo de Trabajo TDD en Laravel

    Desarrollo guiado por pruebas para aplicaciones Laravel usando PHPUnit y Pest con 80%+ de cobertura (unit + feature).

    Cuándo Usar

    • Nuevas funcionalidades o endpoints en Laravel
    • Correcciones de bugs o refactorizaciones
    • Probar modelos Eloquent, policies, jobs y notifications
    • Preferir Pest para pruebas nuevas a menos que el proyecto ya esté estandarizado en PHPUnit

    Cómo Funciona

    Ciclo Rojo-Verde-Refactorizar

    1. Escribir una prueba fallida
    2. Implementar el cambio mínimo para que pase
    3. Refactorizar manteniendo las pruebas en verde

    Capas de Prueba

    • Unit: clases PHP puras, objetos de valor, servicios
    • Feature: endpoints HTTP, autenticación, validación, policies
    • Integration: base de datos + colas + límites externos

    Elegir capas según el alcance:

    • Usar pruebas Unit para lógica de negocio pura y servicios.
    • Usar pruebas Feature para HTTP, autenticación, validación y forma de respuesta.
    • Usar pruebas Integration cuando se validen BD/colas/servicios externos juntos.

    Estrategia de Base de Datos

    • RefreshDatabase para la mayoría de pruebas feature/integration (ejecuta migraciones una vez por ejecución de prueba, luego envuelve cada prueba en una transacción cuando está soportado; las bases de datos en memoria pueden re-migrar por prueba)
    • DatabaseTransactions cuando el esquema ya está migrado y solo se necesita rollback por prueba
    • DatabaseMigrations cuando se necesita un migrate/fresh completo para cada prueba y se puede asumir el costo

    Usar RefreshDatabase como predeterminado para pruebas que tocan la base de datos: para bases de datos con soporte de transacciones, ejecuta las migraciones una vez por ejecución de prueba (mediante un flag estático) y envuelve cada prueba en una transacción; para SQLite :memory: o conexiones sin transacciones, migra antes de cada prueba. Usar DatabaseTransactions cuando el esquema ya está migrado y solo se necesitan rollbacks por prueba.

    Elección del Framework de Pruebas

    • Usar Pest por defecto para pruebas nuevas cuando esté disponible.
    • Usar PHPUnit solo si el proyecto ya lo estandariza o requiere herramientas específicas de PHPUnit.

    Ejemplos

    Ejemplo con PHPUnit

    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']);
        }
    }
    

    Ejemplo de Prueba Feature (Capa HTTP)

    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']);
        }
    }
    

    Ejemplo con Pest

    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']);
    });
    

    Ejemplo de Prueba Feature con Pest (Capa HTTP)

    use App\Models\Project;
    use App\Models\User;
    use Illuminate\Foundation\Testing\RefreshDatabase;
    
    use function Pest\Laravel\actingAs;
    
    uses(RefreshDatabase::class);
    
    test('projects index returns paginated results', function () {
        $user = User::factory()->create();
        Project::factory()->count(3)->for($user)->create();
    
        $response = actingAs($user)->getJson('/api/projects');
    
        $response->assertOk();
        $response->assertJsonStructure(['success', 'data', 'error', 'meta']);
    });
    

    Factories y Estados

    • Usar factories para datos de prueba
    • Definir estados para casos límite (archivado, admin, trial)
    $user = User::factory()->state(['role' => 'admin'])->create();
    

    Pruebas de Base de Datos

    • Usar RefreshDatabase para estado limpio
    • Mantener las pruebas aisladas y deterministas
    • Preferir assertDatabaseHas sobre consultas manuales

    Ejemplo de Prueba de Persistencia

    use App\Models\Project;
    use Illuminate\Foundation\Testing\RefreshDatabase;
    use Tests\TestCase;
    
    final class ProjectRepositoryTest extends TestCase
    {
        use RefreshDatabase;
    
        public function test_project_can_be_retrieved_by_slug(): void
        {
            $project = Project::factory()->create(['slug' => 'alpha']);
    
            $found = Project::query()->where('slug', 'alpha')->firstOrFail();
    
            $this->assertSame($project->id, $found->id);
        }
    }
    

    Fakes para Efectos Secundarios

    • Bus::fake() para jobs
    • Queue::fake() para trabajo en cola
    • Mail::fake() y Notification::fake() para notificaciones
    • Event::fake() para eventos de dominio
    use Illuminate\Support\Facades\Queue;
    
    Queue::fake();
    
    dispatch(new SendOrderConfirmation($order->id));
    
    Queue::assertPushed(SendOrderConfirmation::class);
    
    use Illuminate\Support\Facades\Notification;
    
    Notification::fake();
    
    $user->notify(new InvoiceReady($invoice));
    
    Notification::assertSentTo($user, InvoiceReady::class);
    

    Pruebas de Autenticación (Sanctum)

    use Laravel\Sanctum\Sanctum;
    
    Sanctum::actingAs($user);
    
    $response = $this->getJson('/api/projects');
    $response->assertOk();
    

    HTTP y Servicios Externos

    • Usar Http::fake() para aislar APIs externas
    • Verificar payloads salientes con Http::assertSent()

    Objetivos de Cobertura

    • Aplicar 80%+ de cobertura para pruebas unit + feature
    • Usar pcov o XDEBUG_MODE=coverage en CI

    Comandos de Prueba

    • php artisan test
    • vendor/bin/phpunit
    • vendor/bin/pest

    Configuración de Pruebas

    • Usar phpunit.xml para establecer DB_CONNECTION=sqlite y DB_DATABASE=:memory: para pruebas rápidas
    • Mantener un entorno separado para pruebas para evitar tocar datos de desarrollo/producción

    Pruebas de Autorización

    use Illuminate\Support\Facades\Gate;
    
    $this->assertTrue(Gate::forUser($user)->allows('update', $project));
    $this->assertFalse(Gate::forUser($otherUser)->allows('update', $project));
    

    Pruebas Feature con Inertia

    Al usar Inertia.js, verificar el nombre del componente y las props con los helpers de testing de Inertia.

    use App\Models\User;
    use Inertia\Testing\AssertableInertia;
    use Illuminate\Foundation\Testing\RefreshDatabase;
    use Tests\TestCase;
    
    final class DashboardInertiaTest extends TestCase
    {
        use RefreshDatabase;
    
        public function test_dashboard_inertia_props(): void
        {
            $user = User::factory()->create();
    
            $response = $this->actingAs($user)->get('/dashboard');
    
            $response->assertOk();
            $response->assertInertia(fn (AssertableInertia $page) => $page
                ->component('Dashboard')
                ->where('user.id', $user->id)
                ->has('projects')
            );
        }
    }
    

    Preferir assertInertia sobre aserciones JSON crudas para mantener las pruebas alineadas con las respuestas de Inertia.

    Alternatives

    Compare before choosing