No es necesario colocar todo el path del controlador para llamar la funcion dentro de una tura, basta con [nombreDelControlador]@[nombreDeLa funcion], en el ejemplo quedaria asi:
Route::post('/profile', 'ProfileController@upload');
Cuando programas con confianza, sabes que cada cambio en tu código está respaldado por pruebas que verifican su correcto funcionamiento. La refactorización es precisamente eso: reorganizar y mejorar tu código sin alterar el comportamiento esperado, asegurándote de que tus tests sigan pasando en verde.
¿Qué significa refactorizar sin modificar las pruebas?
La refactorización consiste en alterar el código fuente sin tocar las pruebas existentes [0:12]. Ya sabemos que nuestro testing funciona correctamente. Como programadores, el objetivo es lograr una mejor organización del código, pero las pruebas deben seguir obteniendo resultados positivos. Si algo se rompe, los tests nos lo indican de inmediato.
Esto garantiza algo fundamental: no hemos roto ninguna parte del programa. En lugar de verificar manualmente cada funcionalidad en el navegador, confiamos en un sistema automatizado que actúa como un pequeño robot revisando todo por nosotros [2:28].
¿Cómo se aplica la refactorización en un proyecto Laravel?
El ejemplo práctico parte de mover lógica que estaba directamente en las rutas hacia un controlador dedicado. El proceso se desarrolla así:
php artisan make:controller ProfileController [0:43].App\Http\Controllers\ProfileController::class con el método correspondiente [1:10].¿Qué sucede cuando las pruebas fallan tras el cambio?
Al ejecutar los tests después de mover el código, las pruebas se rompen [1:34]. El sistema indica que no encuentra el archivo esperado y que la afirmación devuelve falso. Este momento es clave: los tests están cumpliendo su función al alertarnos de que algo falta en nuestra nueva configuración.
El error en este caso fue no haber creado el método dentro del controlador. Una vez que se define el método que recibe el request, sube la foto y redirecciona a profile [2:08], los tests vuelven a pasar correctamente.
¿Por qué los tests validan que no se dañó nada?
Al ejecutar nuevamente las pruebas y obtener verde [2:18], confirmamos que:
¿Cuándo cobra mayor importancia el testing en proyectos reales?
Imagina un sistema con mil funciones y necesitas modificar una de ellas [2:48]. Ejecutar todos los tests te permite verificar que el resto del sistema sigue funcionando sin problemas. Esto es especialmente valioso cuando enfrentas escenarios como realizar múltiples mejoras antes de una entrega.
Sin tests, presentar un proyecto al cliente genera incertidumbre: no sabes si algún cambio pudo haber afectado otra parte del sistema [3:04]. Con pruebas automatizadas, cada luz verde te da la confianza necesaria para entregar sabiendo que todo funciona correctamente.
La próxima vez que reorganices tu código, recuerda que la refactorización no se trata solo de escribir mejor, sino de demostrar con evidencia que nada se ha roto. ¿Has tenido alguna experiencia donde los tests te salvaron de un error inesperado? Comparte tu historia.
Cuando programas con confianza, sabes que cada cambio en tu código está respaldado por pruebas que verifican su correcto funcionamiento. La refactorización es precisamente eso: reorganizar y mejorar tu código sin alterar el comportamiento esperado, asegurándote de que tus tests sigan pasando en verde.
La refactorización consiste en alterar el código fuente sin tocar las pruebas existentes [0:12]. Ya sabemos que nuestro testing funciona correctamente. Como programadores, el objetivo es lograr una mejor organización del código, pero las pruebas deben seguir obteniendo resultados positivos. Si algo se rompe, los tests nos lo indican de inmediato.
Esto garantiza algo fundamental: no hemos roto ninguna parte del programa. En lugar de verificar manualmente cada funcionalidad en el navegador, confiamos en un sistema automatizado que actúa como un pequeño robot revisando todo por nosotros [2:28].
El ejemplo práctico parte de mover lógica que estaba directamente en las rutas hacia un controlador dedicado. El proceso se desarrolla así:
php artisan make:controller ProfileController [0:43].App\Http\Controllers\ProfileController::class con el método correspondiente [1:10].Al ejecutar los tests después de mover el código, las pruebas se rompen [1:34]. El sistema indica que no encuentra el archivo esperado y que la afirmación devuelve falso. Este momento es clave: los tests están cumpliendo su función al alertarnos de que algo falta en nuestra nueva configuración.
El error en este caso fue no haber creado el método dentro del controlador. Una vez que se define el método que recibe el request, sube la foto y redirecciona a profile [2:08], los tests vuelven a pasar correctamente.
Al ejecutar nuevamente las pruebas y obtener verde [2:18], confirmamos que:
Imagina un sistema con mil funciones y necesitas modificar una de ellas [2:48]. Ejecutar todos los tests te permite verificar que el resto del sistema sigue funcionando sin problemas. Esto es especialmente valioso cuando enfrentas escenarios como realizar múltiples mejoras antes de una entrega.
Sin tests, presentar un proyecto al cliente genera incertidumbre: no sabes si algún cambio pudo haber afectado otra parte del sistema [3:04]. Con pruebas automatizadas, cada luz verde te da la confianza necesaria para entregar sabiendo que todo funciona correctamente.
La próxima vez que reorganices tu código, recuerda que la refactorización no se trata solo de escribir mejor, sino de demostrar con evidencia que nada se ha roto. ¿Has tenido alguna experiencia donde los tests te salvaron de un error inesperado? Comparte tu historia.
No es necesario colocar todo el path del controlador para llamar la funcion dentro de una tura, basta con [nombreDelControlador]@[nombreDeLa funcion], en el ejemplo quedaria asi:
Route::post('/profile', 'ProfileController@upload');
Este curso es definitivamente una maravilla... !!! Y aunque ya está grabado hace unos años, sigue super vigente y necesario.... Bien por Platzi y el profesor Ítalo....
tener en cuenta que tests automatizados es uno de los stage de devOps. programes en el lenguaje que programes es muy recomendable aprender algo de test
Rojo -> Verde -> Azul
David Soto Ayala
No es necesario colocar todo el path del controlador para llamar la funcion dentro de una tura, basta con [nombreDelControlador]@[nombreDeLa funcion], en el ejemplo quedaria asi:
Route::post('/profile', 'ProfileController@upload');
Jimmy Buriticá Londoño
Edgar Torres
Como lo comenta el compañero es correcto, tambien funcionaria colocando
Route::post('profile', 'ProfileController@upload');
la diferencia es que en laravel 8 hay que descomentar dentro de la carpeta Providers/RouteServiceProvider la linea de codigo que hace reeferencia al 'namespace' utilizado para los controladores
Juan Guillermo Perez Cardozo
tener en cuenta que tests automatizados es uno de los stage de devOps. programes en el lenguaje que programes es muy recomendable aprender algo de test
Brian Sánchez Izquierdo
Rojo -> Verde -> Azul
En Laravel 8 no funciona como lo estas definiendo. La forma en que lo define el profesor es la correcta. Para que funcione similar a lo que propones deberías de llamar el controlador así:
use App\Http\Controllers\ProfileController; Route::get('/profile', [ProfileController::class, 'upload']);
Ver documentación de rutas en Laravel.com