¿Haz escuchando alguna vez estos términos 🔝?
Lo primero que debemos aclarar es que TDD es una metodología de desarrollo, la cuál nos permite escribir un código "aprueba de fallos" (imposible 😂). Al momento de escribir código se tiene que considerar estas 3 reglas:
- Siempre se debe de iniciar escribiendo al menos una prueba unitaria que falle.
- Implementar el código que satisfaga la prueba definida en el punto uno.
- Refactoriza el código si es necesario
- Si es necesario implementar más lógica, se vuelve a empezar al punto 1 🤔
Al inicio es un poco extraño el proceso sobre todo en el punto 3 y 4, pero después de intentarlo se aclararan las dudas.*
Para expandir y explicar más cada punto, les pongo este ejemplo.
Necesitamos construir una función que nos devuelva el tiempo que ha pasado desde que se hizo un comentario en una foto (como en Facebook) y que se vea de esta manera:
- Si el tiempo es menor a una hora, muestra los minutos que han pasado ej. 20min atrás
- Si es más de una hora atrás, muestra la hora original del comentario en formato 24hrs ej. 10:10
- Si es igual o más de un día atrás, muestra la fecha original del comentario ej. 15/09/2020
Si ponemos atención a estos requerimientos, son nuestros casos, los que vamos a definir en nuestras pruebas por ende, este es el paso 1.
La funcion se muestra en rojo porque no la hemos implementado (lo cual es correcto), así que si corremos los test vamos a obtener un error de no existe (estoy utilizando Typescript), voy a crear la función vacía para asegurarme de que todos los casos fallen
Paso 2, implementar el código que satisfaga nuestras pruebas. Una vez que todo esté en verde podemos seguir al siguiente punto.
Resultado:
Pasó 3. NO me juzguen 😂, la implementación de arriba no es la mejor, pero podemos refactorizar sin problemas porque tenemos pruebas que nos respaldan, si algo esta mal, las pruebas lo dirán.
¡Mucho mejor! ¡Y siguen pasando los tests!
Paso 4. Si vas a construir nueva lógica que no es cubierta por ninguno de la pruebas ya definidas, debes de detener ahí, y volver al punto 1.
No estoy seguro de entenderlo, ¿cual es la idea?
Su objetivo esta en que las pruebas den guía del código y no viceversa, esto nos ayuda asegurarnos que la mayoría de casos se cubran, como resultado menos errores en el código.
¿Porque casi no escuchando de TDD?
Es una práctica que tiene mucho tiempo de existir, y no es tan popular por el hecho que cambia la manera en las programamos, y la realidad es que al inicio toma un tiempo acostumbrarse pero es posible de hacer.
¿Siempre debería hacer TDD?
Mi opinión es, cuando sea posible, en realidad hay casos en los que se puede volver complicado. Pongámonos en al situación en que queremos hacer TDD para construir el HTML de un componente, utilizando herramientas convencionales para seleccionar elementos (a través de selectores), ¿Que va a pasar si el selector cambia? La prueba se quiebra.
Por el otro lado, existen otras situaciones como la del ejemplo anterior en la que vamos a poder hacer TDD y probar resultados de una manera simple.
Conclusión
TDD es una práctica que nos obliga a escribir nuestras pruebas unitarias primero para intentar asegurarnos cubrir todos los casos posibles, requiere constancia y dedicación para "masterizar"esta forma de programar. Recomiendo que lo hagan, fácilmente encontrarán las situaciones en las que tiene o no tiene sentido hacerlo.
—
¿Quieres invitarme a un cafecito?
Top comments (0)