Dominar el ciclo rojo, verde y refactorización es fundamental para escribir código limpio respaldado por pruebas automatizadas. Aquí se completa ese ciclo aplicando una mejora de código sin alterar resultados y se construye un nuevo test que impide guardar datos en blanco en los posts.
¿Qué es la refactorización y cómo se aplica en un controlador?
La refactorización consiste en mejorar el código existente sin cambiar su comportamiento. El test debe seguir pasando con las mismas afirmaciones y el resultado debe mantenerse en verde [0:24].
En el PostController se crea un método constructor, es decir, el método que se ejecuta automáticamente cada vez que se accede a la clase. Dentro de él se define una propiedad protegida que representa a la entidad Post [0:42]:
- Se declara la propiedad
protected $post.
- En el constructor se recibe la entidad
Post como parámetro.
- Se asigna esa entidad a la propiedad con
$this->post.
Gracias a este cambio, en lugar de invocar directamente la entidad dentro de cada método, se utiliza $this->post->create(). El código se entiende mucho mejor y la prueba sigue pasando sin alteraciones [1:22]. Esa es la esencia de la refactorización: mejorar la legibilidad sin romper nada.
¿Cómo crear un test que valide títulos en blanco?
El siguiente paso es escribir una nueva prueba que verifique qué sucede cuando se intenta guardar un post sin título [1:42]. El nombre del método puede ser cualquiera, pero siempre debe comenzar con la palabra test.
¿Qué significa el status HTTP 422?
Cuando se envía una solicitud bien formada pero imposible de completar, el servidor responde con el status HTTP 422 (Unprocessable Entity) [2:10]. En este caso, la solicitud no puede procesarse porque falta el campo obligatorio del título.
La prueba verifica dos cosas:
- Que la respuesta devuelva un status 422.
- Que el JSON de errores incluya la variable
title, confirmando que el título no es válido.
Al ejecutar la prueba sin código de validación, se obtiene un error 500 en lugar del 422 esperado [2:48]. Esto ocurre porque el servidor intenta guardar un registro con un campo obligatorio vacío y falla internamente.
¿Cómo construir la validación con un form request?
Para que la prueba pase, se necesita crear un request dedicado a la validación [3:10]. Este archivo se genera con un comando de Artisan y se configura de la siguiente manera:
- Se establece el método
authorize en true para permitir el acceso.
- Se define la regla de validación indicando que el título es obligatorio (required).
Después se conecta este request al controlador. Al importar la clase, surge un conflicto de nombres porque ya existe una referencia a Post como entidad [3:42]. La solución es utilizar un alias: se renombra la importación como PostRequest para distinguirla claramente del modelo.
php
use App\Http\Requests\Post as PostRequest;
Con esta configuración, el método store del controlador recibe PostRequest en lugar del request genérico, activando automáticamente las reglas de validación antes de ejecutar cualquier lógica.
¿Por qué separar cada validación en su propio test?
Al ejecutar las pruebas, ahora se confirman dos tests con diez afirmaciones, todos en verde [4:18]. Un detalle importante de la metodología es que la validación no se agregó dentro del test del método store original. Se creó un método de prueba independiente llamado específicamente para validación [4:30].
Esta separación permite:
- Identificar rápidamente qué falla cuando un test no pasa.
- Mantener cada prueba enfocada en una sola responsabilidad.
- Facilitar que otros programadores comprendan el propósito de cada test.
La metodología TDD (Test Driven Development) sigue siempre el mismo orden: primero rojo (la prueba falla), luego verde (se escribe el código mínimo para que pase) y finalmente refactorización (se mejora sin alterar resultados). Aplicar este ciclo de forma disciplinada garantiza código de calidad respaldado por pruebas confiables.
¿Has aplicado esta metodología en tus proyectos? Comparte tu experiencia y las dificultades que encontraste al implementar TDD por primera vez.
