Cuando trabajas con Laravel, no solo necesitas dominar los métodos que el framework te ofrece, sino también saber crear y validar tus propios métodos personalizados. Aquí se explica paso a paso cómo generar un método href dentro de un modelo Post, probarlo con un test y entender por qué este flujo de trabajo es fundamental para cualquier proyecto profesional.
¿Cómo se estructura un test para un método personalizado?
El punto de partida es un archivo de test ya existente, en este caso PostTest.php. Dentro de él se puede agregar la cantidad de métodos que se necesite; cada uno debe comenzar con la palabra test [01:02].
Para probar la generación de un enlace, se crea un método llamado test_href. Dentro de él se instancia un nuevo Post y se le asigna un nombre:
php
$post = new Post();
$post->name = 'Proyecto en PHP';
Lo que se espera es que, al llamar a $post->href(), el resultado sea una URL con formato de slug: /blog/proyecto-en-php [01:30]. Toda la cadena debe estar en minúscula y con guiones en lugar de espacios.
La aserción se escribe con assertEquals o el método equivalente que corresponda, comparando la URL esperada con el valor que retorna href().
¿Qué sucede cuando el método aún no existe?
Al ejecutar el test con el comando php artisan test --filter seguido del nombre del test [02:10], Laravel lanza un error indicando que el método href no existe en el modelo. Este comportamiento es completamente esperado y forma parte del enfoque de programar con intención: primero defines qué resultado quieres obtener y después escribes el código que lo produce.
¿Cómo se implementa el método href en el modelo Post?
Dentro del modelo Post se agrega un método público:
php
public function href()
{
return "/blog/{$this->slug}";
}
Este método simplemente concatena la ruta /blog/ con el valor del slug del post [02:40]. El slug ya se obtiene a través de un accessor previamente configurado con get y Attribute, una funcionalidad que provee directamente el framework.
Al volver a correr el test, el resultado es exitoso: el método href retorna exactamente la URL esperada.
¿Por qué es válido duplicar código en los tests?
Una observación importante es que, a nivel de tests, puede parecer que se está duplicando código [03:15]. Sin embargo, esto es intencional. Los tests deben ser claros y autocontenidos para que cualquier desarrollador pueda leerlos en el futuro y comprender de inmediato qué se está validando.
Cada test cuenta una historia completa:
- Se crea un post con un nombre específico.
- Se verifica que el método
href retorne la URL correcta en formato slug.
- Se documenta la intención detrás de la programación.
¿Cuál es la diferencia entre un método personalizado y un accessor del framework?
Es clave distinguir entre ambos. Cuando se define un método con la convención get + nombre + Attribute, se está utilizando un accessor que Laravel reconoce y ejecuta automáticamente al acceder a una propiedad del modelo [03:00]. En cambio, un método como href() es completamente personalizado: no depende de ninguna convención del framework, y su lógica interna puede ser tan simple o compleja como se requiera.
¿Qué significa programar con intención usando testing?
El concepto central es que los tests no son un paso posterior, sino parte integral del proceso de desarrollo [03:45]. El flujo es claro:
- Definir la expectativa: escribir el test que describe el resultado deseado.
- Observar el fallo: ejecutar el test y confirmar que falla porque el código aún no existe.
- Implementar la solución: crear el método que satisface la expectativa.
- Verificar el éxito: correr el test nuevamente y confirmar que pasa.
Este enfoque garantiza que, cuando otro programador modifique el proyecto en el futuro, pueda ejecutar todos los tests y detectar de inmediato si algún cambio ha roto funcionalidad previamente validada.
Si tienes dudas sobre cómo aplicar este flujo en tus propios modelos, comparte tu experiencia en los comentarios.
