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).
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
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
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.
npx skills add https://github.com/affaan-m/ECC --skill "docs/es/skills/laravel-tdd"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
- 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 - 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 - 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 - 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 - 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
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 73/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 234,327 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated 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
- Escribir una prueba fallida
- Implementar el cambio mínimo para que pase
- 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
RefreshDatabasepara 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)DatabaseTransactionscuando el esquema ya está migrado y solo se necesita rollback por pruebaDatabaseMigrationscuando 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
RefreshDatabasepara estado limpio - Mantener las pruebas aisladas y deterministas
- Preferir
assertDatabaseHassobre 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 jobsQueue::fake()para trabajo en colaMail::fake()yNotification::fake()para notificacionesEvent::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
pcovoXDEBUG_MODE=coverageen CI
Comandos de Prueba
php artisan testvendor/bin/phpunitvendor/bin/pest
Configuración de Pruebas
- Usar
phpunit.xmlpara establecerDB_CONNECTION=sqliteyDB_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
affaan-m/ECC
laravel-tdd
Laravel testing strategies with PHPUnit, Pest, model factories, HTTP tests, Sanctum authentication testing, mocking, and coverage.
affaan-m/ECC
laravel-tdd
Test-driven development for Laravel with PHPUnit and Pest, factories, database testing, fakes, and coverage targets.
affaan-m/ECC
laravel-tdd
Review laravel-tdd's use cases, installation, workflow, and original source instructions.
affaan-m/ECC
laravel-tdd
Review laravel-tdd's use cases, installation, workflow, and original source instructions.