Desarrollo impulsado por pruebas (tdd)

Definición - ¿Qué significa desarrollo impulsado por pruebas (TDD)?

El desarrollo impulsado por pruebas (TDD) es un enfoque de desarrollo de software en el que se escribe una prueba antes de escribir el código. Una vez que el nuevo código pasa la prueba, se refactoriza a un estándar aceptable.

TDD garantiza que el código fuente se someta a pruebas unitarias exhaustivas y conduce a un código modularizado, flexible y extensible. Se enfoca en escribir solo el código necesario para aprobar las pruebas, haciendo que el diseño sea simple y claro.

Techinfo explica el desarrollo basado en pruebas (TDD)

TDD permite al programador realizar pequeños pasos mientras escribe software. La prueba se escribe antes de probar la funcionalidad y garantiza que la aplicación sea adecuada para la prueba. Se realizan pruebas en una pequeña cantidad de código para atrapar errores que ocurren en el código probado. Luego se implementa la funcionalidad. Esto se conoce como "refactorización verde rojo", donde el rojo significa fallar y el verde muestra un pase. Luego se repiten estos pasos. El primer objetivo de un programador es concentrarse en la tarea que tiene entre manos y aprobarla.

Los diferentes pasos involucrados en un ciclo de desarrollo impulsado por pruebas son:

  • Agregar una prueba: cada característica nueva en TDD comienza con una prueba que debe fallar a medida que se implementa antes de que se implemente cualquier característica. El requisito esencial para escribir una prueba antes de la implementación de funciones es una comprensión clara del requisito por parte del desarrollador. Esto se logra a través de historias de usuarios y casos de uso. Por lo tanto, un desarrollador comprende el requisito antes de escribir el código del programa.
  • Ejecute todas las pruebas y verifique si el nuevo código falla: Esto asegura el funcionamiento correcto del arnés de prueba y que la nueva prueba no pasa por error sin ningún código nuevo. Este paso también prueba la prueba y elimina la posibilidad de que la nueva prueba siempre pase.
  • Escribir código: el siguiente paso que sigue es escribir código que borra la prueba. El nuevo código no es perfecto, pero luego se modifica según los requisitos. Simplemente está diseñado para pruebas y no incluye otras funcionalidades.
  • Ejecutar pruebas automatizadas: si cada caso de prueba producido pasa fácilmente la prueba, implica que el código cumple con todas las especificaciones requeridas. Por tanto, se puede iniciar el último paso del ciclo.
  • Refactorizar código: es similar a eliminar la duplicación. Una refactorización no daña ninguna funcionalidad existente y ayuda a eliminar la duplicación entre los códigos de producción y de prueba. El código ahora se limpia según sea necesario.
  • Repetir: El ciclo se repite como en los casos anteriores con una nueva prueba. El requisito esencial es que el tamaño de los pasos debe ser pequeño, con alrededor de 1 a 10 ediciones entre cada ejecución de prueba. Si el nuevo código no satisface una nueva prueba, el programador debe realizar una depuración adicional. La integración continua proporciona puntos de control reversibles.