Cuando trabajamos con TDD (Test-Driven Development), existe una fase que muchos subestiman pero que marca la diferencia en la calidad del código: la refactorización. Después de obtener el rojo con una prueba fallida y el verde al escribir el código que la hace pasar, llega el momento opcional pero valioso de mejorar la estructura sin alterar el funcionamiento. Aquí es donde entran las políticas de acceso en Laravel como una herramienta poderosa para limpiar nuestros controladores.

¿Qué son las políticas de acceso y por qué usarlas?

Las políticas de acceso (policies) en Laravel permiten aislar la lógica de autorización que normalmente vive dentro de los controladores. Ese if que valida si un usuario tiene permiso sobre un recurso puede —y debe— separarse en su propio archivo para que el código sea más legible y mantenible.

El proceso comienza generando la política desde el terminal [1:00]:

• Se ejecuta php artisan make:policy seguido del nombre, que por convención termina en Policy.
• Laravel crea automáticamente una carpeta llamada Policies con el archivo correspondiente.
• Dentro de esa clase vacía, se pueden definir métodos específicos como pass, edit, create o update.

En este caso, se crea un único método llamado pass porque la condicional es la misma para todas las operaciones: verificar que el ID del usuario autenticado coincida con el user_id del repositorio [2:30].

¿Cómo se configura y registra una política?

Una vez creado el archivo, hay tres pasos esenciales:

• Crear la política con el comando artisan.
• Configurar el método que contiene la lógica de autorización.
• Registrar la política en el AuthServiceProvider para que Laravel asocie el modelo con su política correspondiente.

En el AuthServiceProvider se descomenta el ejemplo que Laravel provee y se vincula la entidad (el modelo de repositorio) con la política recién creada [3:15]. Esta asociación es lo que permite usar el método authorize dentro del controlador.

¿Cómo se aplica la política en el controlador?

Dentro del controlador de repositorios, la sustitución es directa [3:50]:

• Se reemplaza cada condicional if por una llamada a $this->authorize('pass', $repository).
• El primer parámetro indica qué método de la política evaluar.
• El segundo parámetro es el dato sobre el cual se verifica el permiso.

Esto reduce significativamente las líneas de código y mejora la legibilidad. Cada método del controlador queda más limpio al delegar la responsabilidad de autorización a la política.

¿Por qué los tests son fundamentales durante la refactorización?

Al realizar cambios estructurales, los tests funcionan como una red de seguridad. Mientras la refactorización no esté completa, las pruebas lo señalan con errores claros [4:40]:

• Si se elimina el parámetro $request del controlador pero no se actualiza el acceso al usuario, los tests fallan.
• Al cambiar la forma de obtener el usuario autenticado (por ejemplo, usando auth()->user() en lugar de $request->user()), los tests confirman que todo sigue funcionando.
• Cada método donde ya no se usa una variable innecesaria se limpia, y los tests validan que no se rompió nada.

Al ejecutar php artisan test después de completar todos los cambios, todas las pruebas pasan exitosamente [5:50]. La esencia del testing queda demostrada: una modificación amplia que no altera el funcionamiento del sistema.

¿Qué pasa si no tenemos tests al refactorizar?

Imagina un escenario real: necesitas presentar tu proyecto a un cliente mañana y decides hacer una mejora importante hoy. Sin tests, no hay forma de saber con certeza si alguna parte del proyecto se dañó durante el cambio. La presentación se convierte en un momento de inseguridad.

Con tests, en cambio, cada modificación queda respaldada por validaciones automáticas que confirman que el sistema funciona correctamente. Esto es especialmente relevante en entornos laborales donde las refactorizaciones son frecuentes y los equipos necesitan confianza al desplegar cambios.

La combinación de políticas de acceso para organizar la autorización y TDD para garantizar estabilidad representa una práctica profesional que vale la pena incorporar en cualquier proyecto Laravel. ¿Has implementado políticas en tus proyectos? Comparte tu experiencia en los comentarios.