Metodología TDD y testing HTTP

Paso 1: Crear prueba, para obtener rojo
Paso 2: Crear código para cumplir con esa prueba, para obtener verde
Paso 3: Refactorización es una revisión posterior de revisar, organizar, crear métodos, para seguir consiguiendo verde sin alterar la prueba.

El ciclo del TDD:

Metodología TDD y testing HTTP

La metodología TDD tiene trece pasos a cumplir:

1. Rojo → Creamos una prueba que va a fallar por defecto.
2. Verde → Construimos el código para que la prueba acierte.
3. Refactorización → Vamos a mejorar nuestro código para que sea más elegante y simple pero sigue sirviendo igual.

Testing HTTP Métodología TDD

Testing HTPP -> Probar los accessos HTTP

Metodología TDD

Significa Desarrollo guiado por pruebas, o Tests-Driven Development es una práctica de ingeniería de software que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring).

Paso para la creación de Testing

1. Rojo -> En este paso se crea la prueba la cual no tiene código creado y tiende a generar un fallo.

2. Verde -> En verde se construye en código más sencillo para que la prueba funcione. En este paso es muy recomendado usar el principio KISS.

3. Refactorización: Se trata de construir nuestro código de manera elegante y entendible para que nuestros compañeros lo entiendan, además de que le mismo mantenga el mismo no latera la prueba y mantenga el estado verde.

Comando para crear una prueba:

php artisan make:test PageTest

Comando para correr test:

php artisan test

También podemos utilizar

php artisan test

para correr los tests. En mi opinión se ve mejor y es mas intuitivo.

En testing

el primer paso se llama rojo

• creo mi prueba pero sin codigo en MVC, por lo que me manda un error, esto es rojo

Segundo paso verde

• tengo codigo en la prueba
• mi codigo de trabajo funciona
• mi test o prueba consulta bien a mi codigo de trabajo

tercer paso refactorizacion

• mejora la escritura del codigo
• se agregan comentarios
• se facilita el entender este codigo

Primeros pasos con TDD:

1. Escribir las pruebas (ROJO)
2. Escribir el código que pase las pruebas (VERDE)
3. Refactorizar el código para mejorarlo (Refactor)

Vale, crear código del test, crear el código de la apicación y refactorizar, aún así, me parece un poco extraño, es decir, ¿Pr qué no puedo crear mi código ya “refactorizado” y luego crear el test? 🤔

Muy interesante este tema de las pruebas, es un poco difícil, porque va contra nuestra lógica. Toca volver a configurarnos. Todo sea por ser un mejor programador.

Test unit y simple pero poderosa

Tenía dudas de porqué usabamos la carpeta de Feature en vez de Unit para los test y conseguí lo siguiente:

La carpeta Unit se utiliza para guardar tests muy específicos sobre un fragmento de código y en Feature guardaremos los test en los que realizaremos comprobaciones más complejas.

Más info acá : https://cosasdedevs.com/posts/test-unitarios-unit-test-en-nuestro-blog-con-laravel-8/

empezamos:
a- Escribir las pruebas (ROJO)
b- Escribir el código que pase las pruebas (VERDE)
c- Refactorizar el código para mejorarlo (Refactor)

para crear un proyecto de Laravel como api se usa el mismo comando? o hay un comando especial para que sea usado solo como API? (que no integre blade o cosas que usan en vistas)

chicos consulta, tengo problemas con el vendor/bin/phpunit, ¿Saben que problema puede ser? o tiene alguna diferencia con php artisan test

de acuerdo
rojo ->creas
verde ->hacer funcionar
refactorizacion ->mejorar

El TDD es una metodología de desarrollo en la que se construye primero las pruebas y luego el código, los pasos a realizar son:
Rojo: Se crea la prueba sin código, obteniendo el error.
Verde: Se crea el código para validar la prueba hasta que salga en verde.
Refactorizar: Revisar el código para organizarlo mejor, obteniendo aún verde sin alterar la prueba.

1. Crear el test con la nueva funcionalidad
2. Codear la funcionalidad
3. Mejorar ambos pasos

por accidente descubrí que para hacer las pruebas sirve así:
vendor\bin\phpunit
no arroja el error con los “/” slash normales