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
Ejemplo de Prueba Feature (Capa HTTP)
Ejemplo con Pest
Ejemplo de Prueba Feature con Pest (Capa HTTP)
Factories y Estados
- Usar factories para datos de prueba
- Definir estados para casos límite (archivado, admin, trial)
Pruebas de Base de Datos
- Usar
RefreshDatabasepara estado limpio - Mantener las pruebas aisladas y deterministas
- Preferir
assertDatabaseHassobre consultas manuales
Ejemplo de Prueba de Persistencia
Fakes para Efectos Secundarios
Bus::fake()para jobsQueue::fake()para trabajo en colaMail::fake()yNotification::fake()para notificacionesEvent::fake()para eventos de dominio
Pruebas de Autenticación (Sanctum)
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
Pruebas Feature con Inertia
Al usar Inertia.js, verificar el nombre del componente y las props con los helpers de testing de Inertia.
Preferir assertInertia sobre aserciones JSON crudas para mantener las pruebas alineadas con las respuestas de Inertia.

