Estás trabajando en una nueva función y, de repente, una función antigua deja de funcionar a pesar de que escribiste pruebas unitarias. O está refactorizando el código heredado y cree que está hecho, pero de repente encuentra muchos errores. Entonces regresas, haces las correcciones y crees que está hecho, pero luego encuentras más errores. Repites y crees que se hace todo el tiempo, pero siempre sucede lo mismo.
Tiene que escribir pruebas para asegurarse de que su producto funciona, y la única forma de demostrar que funciona es mediante pruebas. Y debe realizar pruebas constantemente para detectar errores de regresión para poder agregar nuevas funciones sin romper las existentes.
Entonces, está trabajando en software con pruebas y, sin embargo, tiene un error en la lógica que ya estaba cubierto por esas pruebas.
Los resultados de su prueba le han dado un falso positivo sobre su software.
Test-Driven Development (TDD) es la mejor solución para este problema. TDD no es prueba de unidad. La prueba de unidad es escribir código para probar nuestro código. Entonces, primero, escribimos nuestro código, y luego escribimos pruebas unitarias para verificar nuestra lógica que acabamos de escribir. Pero TDD es totalmente diferente. Con TDD, primero escribe las pruebas antes de escribir el código.
TDD te obliga a ver tus pruebas fallidas, que te muestran cómo convertirlas en verde cuando reparas estas pruebas fallidas.
Definición de desarrollo basado en pruebas
TDD es una técnica de desarrollo en la que primero debe escribir una prueba que falla, luego escribir código para que funcione y, finalmente, deberá refactorizar el código para que sea lo más simple posible.
En muchos casos, escribir pruebas automatizadas no se considera un trabajo real y aburrido en comparación con la creación de nuevas funciones. TDD, sin embargo, convierte las pruebas en una actividad de diseño. Utilizamos las pruebas que escribimos para aclarar nuestras ideas sobre lo que queremos que haga el código. También mantiene el código lo más simple posible para que sea más fácil de entender y modificar, especialmente porque los desarrolladores pasan más tiempo leyendo el código que escribiéndolo.
A medida que nos desarrollamos en TDD, nos brinda retroalimentación sobre la calidad tanto de su implementación (funciona) como del diseño (está bien estructurada).
Cada nivel de pruebas debe responder preguntas específicas sobre nuestro código.
1. Pruebas de extremo a extremo: ¿Funciona todo el sistema?
2. Pruebas de integración: ¿Nuestros objetos funcionan entre sí correctamente?
3. Pruebas unitarias: ¿Nuestros objetos hacen lo correcto?
Proceso TDD
Primero necesitamos escribir historias de usuarios, que describan el sistema en detalle. Las historias de usuario describen las características comerciales de una manera conveniente para los equipos técnicos para que puedan trabajar en ellas fácilmente.
Más importante que las historias de los usuarios son sus criterios de aceptación, que se utilizan para validar que cada historia se hace o no. Las pruebas sólidas comienzan por escribir criterios de aceptación sólidos.
- Para cada criterio de aceptación, debe escribir una prueba de punta a punta fallida.
- Debe escribir código para que esta prueba de punta a punta pase, escribiendo pruebas de integración fallidas que describan cómo interactuarán sus objetos entre sí.
- Para cada clase, debe escribir una prueba unitaria fallida para probar la salida de cada unidad individual.
- Luego, debe escribir el código real para que las pruebas unitarias pasen para todas las clases, y las pruebas de integración y las pruebas de punta a punta pasan para todos los criterios de aceptación.
Proyecto TDD de ejemplo
Vamos a crear una aplicación que muestre una lista de películas (nombre y calificación). Incluso una pequeña historia (largometraje) como esta es demasiado grande para escribirla de una vez, por lo que debemos averiguar aproximadamente los pasos que podríamos tomar para llegar allí.
Aquí están todas las características requeridas para nuestra aplicación de muestra:
Mostrar una lista de películas.
Aquí está nuestra historia de usuario:
Como usuario, quiero poder ver una vista de lista para poder elegir mi próxima película.
Y aquí está nuestro criterio de aceptación:
La aplicación debe mostrar el nombre y la calificación de cada película.
Ahora podemos comenzar.
Configurando nuestro proyecto…
Te esperamos en los próximos artículos en donde hablaremos mas acerca de estos temas que hoy en día son de importancia e interés en el mundo de la tecnología.
