Qué es Test Driven Development, enfoques y ventajas

Test Driven Development (TDD) es un enfoque de desarrollo de software en el que se desarrollan casos de prueba para especificar y validar lo que hará el código.

Prácticamente se crean y prueban casos de prueba para cada característica antes de lanzar el software, y si la prueba falla, se escribe (o se reescribe o se repara) un nuevo código para pasar la prueba y hacer que el código sea simple y sin errores.

Test Driven Development (TDD) comienza con el diseño y desarrollo de pruebas para cada pequeña característica de una aplicación. El marco TDD indica a los desarrolladores que escriban código nuevo solo si una prueba automatizada ha fallado. Este enfoque evita la duplicación de código. El módulo TDD completo es un desarrollo basado en pruebas.

Test Driven Development (TDD) se originó como parte de un paradigma de diseño de software más amplio conocido como Programación Extrema (XP), que es parte de la metodología de desarrollo de software Agile.

El concepto simple de TDD es escribir y corregir pruebas fallidas antes de escribir código nuevo (antes del desarrollo). Esto ayuda a evitar la duplicación de código ya que escribimos una pequeña cantidad de código a la vez para pasar las pruebas. (Las pruebas no son más que condiciones de requisitos que tenemos que probar para satisfacerlas).

El desarrollo basado en pruebas es un proceso de desarrollo y ejecución de pruebas automatizadas antes del desarrollo real de la aplicación. Por lo tanto, TDD también se llama a veces Test First Development.

Fases del enfoque TDD

Antes de escribir cualquier código nuevo, el programador primero debe crear una prueba de unidad fallida. Luego, el programador, o la pareja, o la mafia, crea el código suficiente para satisfacer ese requisito. Una vez que pasa la prueba, el programador puede refactorizar el proyecto, realizando mejoras sin cambiar el comportamiento.

Si bien TDD se enfoca en las interacciones del programador a nivel de unidad, existen otros métodos populares, como el desarrollo basado en pruebas de aceptación (ATDD) o el desarrollo basado en el comportamiento (BDD), que se enfocan en pruebas que los clientes pueden entender.

Estos métodos implican la creación de ejemplos del mundo real como pruebas colaborativas entre el personal de ingeniería y el cliente antes de la codificación, y luego ejecutar las pruebas después de la codificación para demostrar que se implementa el código. Tener las pruebas conocidas de antemano mejora la calidad de la primera vez. ATDD y BDD requieren que los desarrolladores, evaluadores y el lado comercial trabajen juntos para imaginar y discutir el software y sus implicaciones antes de crear el código.

Ventajas de TDD

El desarrollo basado en pruebas puede producir aplicaciones de alta calidad en menos tiempo que con los métodos más antiguos. La implementación exitosa de TDD requiere que los desarrolladores y evaluadores anticipen con precisión cómo se usará la aplicación y su funcionalidad en el mundo real.

TDD construye un conjunto de pruebas de regresión como un efecto secundario que puede minimizar las pruebas manuales humanas, encontrando problemas antes, lo que lleva a soluciones más rápidas. La naturaleza metódica de TDD garantiza una cobertura y una calidad mucho más altas a la primera que los clásicos ciclos de código en fases > probar > corregir > volver a probar. Debido a que las pruebas se realizan al principio del ciclo de diseño, se minimiza el tiempo y el dinero gastados en la depuración posterior.

Beneficios esperados:

• reducciones significativas en las tasas de defectos, a costa de un aumento moderado en el esfuerzo de desarrollo inicial
• los gastos generales están más que compensados ​​por una reducción en el esfuerzo en las etapas finales de los proyectos
• TDD conduce a mejores cualidades de diseño en el código y, en general, a un mayor grado de calidad técnica o "interna", por ejemplo, al mejorar las métricas de cohesión y acoplamiento.

Desventajas de TDD

TDD requiere una habilidad considerable para tener éxito, especialmente a nivel de unidad. Muchos sistemas heredados simplemente no se construyen teniendo en cuenta las pruebas unitarias, lo que hace imposible aislar los componentes para las pruebas.

Además, muchos programadores carecen de las habilidades para aislar y crear código limpio. Todos los miembros del equipo deben crear y mantener pruebas unitarias o se volverán obsoletas rápidamente. Y una organización que busca TDD tendrá que invertir tiempo, disminuir un poco la velocidad ahora para ir más rápido más adelante.

Finalmente, como con cualquier método, los resultados finales de TDD son tan buenos como las pruebas que se utilizaron, la precisión con la que se realizaron y la medida en que imitan las condiciones encontradas por los usuarios del producto final.

Errores comunes:

• olvidarse de ejecutar pruebas con frecuencia
• escribir demasiadas pruebas a la vez
• escribir pruebas que son demasiado grandes o asquerosas
• escribir pruebas demasiado triviales, como omitir afirmaciones
• escribir pruebas para código trivial
• adopción parcial: solo unos pocos desarrolladores en un grupo de trabajo usan TDD
• mantenimiento deficiente del conjunto de pruebas, lo que más comúnmente conduce a un conjunto de pruebas con un tiempo de ejecución prohibitivamente largo
• conjunto de pruebas abandonado (es decir, rara vez o nunca se ejecuta), a veces debido a un mantenimiento deficiente, a veces debido a la rotación del equipo

Filosofía TDD

TDD permite al programador dar pequeños pasos al escribir software. La prueba se escribe antes de probar la funcionalidad y garantiza que la aplicación sea adecuada para la comprobación. Se realizan pruebas en una pequeña cantidad de código para detectar errores que ocurren en el código probado. Luego se implementa la funcionalidad. Esto se conoce como un "refactor rojo verde", donde el rojo significa falla y el verde muestra aprobación. Luego se repiten estos pasos. El primer objetivo de un programador es concentrarse en la tarea en cuestión y superarla.

Las diferentes etapas involucradas en un ciclo de desarrollo dirigido por pruebas son:

• Agregue una prueba: cada nueva función en TDD comienza con una prueba que debe fallar cuando se implementa antes de que se implemente cualquier función. El requisito previo para escribir una prueba antes de implementar la característica es una comprensión clara del requisito por parte del desarrollador. Esto se logra a través de historias de usuario y casos de uso. Entonces, 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 que el arnés de prueba funcione correctamente y que la nueva prueba no falle sin ningún código nuevo. Este paso también verifica la prueba y elimina la posibilidad de que la nueva prueba siempre pase.
• Escribir código: el siguiente paso que sigue es escribir el código que borra la prueba. El nuevo código no es perfecto, pero luego se modifica según los requisitos. Está diseñado simplemente para probar y no contiene otras características.
• Ejecutar pruebas automatizadas: si cada caso de prueba producido pasa la prueba fácilmente, significa que el código cumple con todas las especificaciones requeridas. Entonces se puede iniciar la fase final del ciclo.
• Código de refactorización: Esto es similar a eliminar la duplicación. Una refactorización no rompe ninguna funcionalidad existente y ayuda a eliminar la duplicación entre el código de producción y el 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 del paso sea pequeño, con entre 1 y 10 cambios entre cada ejecución de prueba. Si el nuevo código falla en una nueva prueba, el programador debería hacer más depuración. La integración continua proporciona puntos de control reversibles.

Ercole Palmeri