Automatizar la verificación de rutas protegidas es una de las prácticas más valiosas cuando trabajas con Laravel. En lugar de abrir el navegador una y otra vez para comprobar que un usuario sin sesión no pueda acceder a ciertas páginas, puedes escribir pruebas que lo hagan por ti y que además queden documentadas en tu proyecto para siempre.
¿Cómo funciona el testing de rutas como si fuera una receta?
El enfoque más sencillo para entender el testing es pensarlo como una receta paso a paso [0:01]. Primero abres el navegador, luego colocas la URL, presionas enter y esperas una respuesta. Exactamente eso es lo que se configura línea a línea dentro de un archivo de prueba: una descripción ordenada de lo que debería ocurrir.
Cuando un usuario invitado —es decir, alguien que no ha iniciado sesión— intenta acceder a una ruta protegida, lo esperado es que el sistema lo redirija al login. Esa expectativa se traduce directamente en código de prueba.
¿Cómo crear el archivo de prueba para un controlador?
El comando utilizado es php artisan make:test seguido de la ruta que refleja la estructura de carpetas del proyecto [1:06]:
bash
php artisan make:test Controllers/RepositoryControllerTest
Esto genera el archivo dentro de tests/Feature/HTTP/Controllers/, manteniendo coherencia con la organización de app/HTTP/Controllers. Dentro del archivo se incluyen las configuraciones habituales para pruebas de tipo feature, como el uso de RefreshDatabase y WithFaker [1:48].
¿Qué se prueba cuando un invitado visita rutas protegidas?
Se configuran siete verificaciones, una por cada ruta que genera un controlador CRUD [2:17]. La primera prueba valida que al visitar el index de repositorios sin sesión activa, ocurra una redirección al login:
php
$this->get(route('repositories.index'))
->assertRedirect('login');
Al ejecutar php artisan test por primera vez, la prueba falla con un 404 porque la ruta aún no existe [3:05]. Esto es completamente normal y forma parte del flujo conocido como red-green testing: primero falla, luego se corrige.
¿Cómo configurar las rutas de recursos con middleware de autenticación?
Para crear las siete rutas de un CRUD de forma automática se utiliza Route::resource en el archivo de rutas [3:20]:
php
Route::resource('repositories', RepositoryController::class)
->middleware('auth');
El middleware auth protege de manera automática las siete rutas que se generan: index, show, create, store, edit, update y destroy [3:50]. Al asignar el middleware a nivel de recurso completo, no es necesario proteger cada ruta individualmente.
También es necesario crear el controlador si no existe:
bash
php artisan make:controller RepositoryController --resource
Tras crear el controlador y corregir un pequeño error tipográfico en el nombre de la ruta [4:33], al ejecutar nuevamente las pruebas el resultado es exitoso: la ruta redirige correctamente al login.
¿Por qué probar las siete rutas del CRUD individualmente?
Aunque la protección se configura en una sola línea con el middleware, cada ruta se prueba por separado [5:15]. Las verificaciones cubren:
- Index: acceso con
GET a la lista de repositorios.
- Show: visualización de un registro específico con
GET.
- Edit: formulario de edición con
GET.
- Update: actualización con
PUT.
- Destroy: eliminación con
DELETE.
- Create: formulario de creación con
GET.
- Store: guardado de un nuevo registro con
POST.
Cada una espera una redirección al login cuando no hay sesión activa [6:10]. La razón de probar individualmente es que en el futuro otro programador podría separar esa única línea de middleware en configuraciones independientes para cada ruta. Al tener las siete pruebas escritas, cualquier cambio que rompa la protección será detectado de inmediato.
Para visualizar todas las rutas disponibles y confirmar su existencia, se puede ejecutar:
bash
php artisan route:list
Este comando muestra el listado completo con métodos HTTP, URIs y nombres asignados [5:30].
El valor real de estas pruebas está en la automatización: lo que normalmente harías manualmente en el navegador —verificar redirecciones, comprobar códigos de estado— queda descrito en un archivo que puedes ejecutar con un solo comando cuantas veces necesites. ¿Ya estás aplicando testing en tus proyectos Laravel? Comparte tu experiencia.
