Beneficios del Desarrollo Guiado por Pruebas: Estadísticas Clave y Estudios
En este artículo, reviso algunas estadísticas y estudios sobre el desarrollo guiado por pruebas para comprender cómo se ha empleado, los beneficios y los desafíos que enfrentan los equipos con este enfoque.
Tradicionalmente, el proceso de desarrollo de software avanza de forma lineal. Sin embargo, en las últimas décadas, a medida que los sistemas ágiles se están volviendo más populares (hasta un 87% de los equipos siguen un enfoque ágil o similar), el desarrollo de software ha comenzado a adoptar diferentes metodologías que toman en cuenta los requisitos y el carácter del proyecto.
La técnica de desarrollo guiado por pruebas (TDD) es uno de los métodos que ha estado captando atención en el área del desarrollo ágil de software.
¿Quieres más de The CTO Club?
Crea una cuenta gratuita para terminar de leer este contenido y unirte a una comunidad de CTOs y líderes de ingeniería que comparten marcos, herramientas y conocimientos reales para diseñar, desplegar y escalar tecnología impulsada por IA.
Have an account? Log In
En un artículo de investigación publicado por el Instituto de Ingenieros Eléctricos y Electrónicos, los autores Yahya Rafique y Vojislav Misic afirman que “El desarrollo guiado por pruebas (TDD) es una de las prácticas fundamentales del proceso de desarrollo de Programación Extrema (XP)” (Fuente).
Se dice que el creador de TDD “declaró en 2003 que TDD fomenta diseños simples e inspira confianza” (Fuente). Sin embargo, aún existen dudas respecto a las afirmaciones sobre la productividad y la calidad hechas sobre TDD.
Nos tomamos un tiempo para recopilar las estadísticas más recientes de TDD para comprobar las afirmaciones realizadas.
Este artículo comienza definiendo el concepto de TDD y cómo se diferencia del enfoque tradicional. Después, analizamos algunas de las estadísticas que validan o rechazan las afirmaciones hechas sobre TDD.
¿Qué es el desarrollo guiado por pruebas?
El desarrollo guiado por pruebas es un enfoque en el que se escribe una prueba antes de que el desarrollador de software cree el código de producción para cumplir con dicha prueba. La idea básica de esta técnica es permitir que el autor del código se tome un tiempo para considerar su diseño o los requisitos antes de escribir el código funcional.
Proceso de TDD
- Redacción de la prueba: En TDD, todas las nuevas funcionalidades comienzan con la redacción de una prueba. El programador debe entender la especificación y los requisitos de la funcionalidad. Para lograrlo, necesitará revisar historias de usuario y casos de uso para comprender el objetivo del nuevo código que está desarrollando.
- La prueba falla: Una vez escrito el test por el programador, se ejecuta. Dado que aún no existe ningún código para implementarla, la prueba fallará. Esto confirma que el marco de pruebas automatizadas funciona correctamente y descarta la posibilidad de que la nueva prueba siempre pase por ser defectuosa.
- Escribir el código: Ahora, el programador sabe que la funcionalidad funciona según el diseño. Ahora escribe el código que pasa la prueba. El código puede no ser perfecto, ni pasar la prueba de manera sobresaliente, pero eso no importa. No se espera que el desarrollador escriba códigos más allá de la funcionalidad para la que se creó la prueba.
- Ejecutar las pruebas: Sabiendo que la funcionalidad funciona como se diseñó, cada vez que lance nuevo código, el programador puede usar una herramienta de gestión de pruebas para ejecutar esa prueba nuevamente, proporcionándole la validación de que su actualización más reciente no ha roto la funcionalidad anterior.
- Refactorización del código: En TDD, a medida que la base de código crece, debe ser limpiada de forma continua. Teniendo en cuenta que el principal enfoque del programador en las etapas anteriores era solo escribir el código, esta etapa garantiza la eficiencia. Permite mejorar la estructura interna del código fuente del programa mientras se preservan sus características externas. Esta etapa puede eliminar duplicaciones y añadir nuevas funcionalidades.
- Repetir: Los pasos anteriores se repiten automáticamente para garantizar que los ciclos de TDD cubran todas las funcionalidades.
Diferencias entre TDD y el desarrollo tradicional
Para entender TDD, parece apropiado determinar cómo se diferencia de los enfoques tradicionales de programación.
La principal diferencia es que los métodos tradicionales siguen un proceso lineal, mientras que TDD pasa por un proceso cíclico.
Los programadores que utilizan los métodos tradicionales de prueba comienzan creando el código y solo se concentran en la prueba al final del proceso de desarrollo. Por otro lado, quien sigue el modelo TDD comienza creando la prueba y luego desarrolla el código que cumpla con la prueba. Este enfoque comparte muchos principios con el movimiento shift left en las pruebas de software.
Mientras que el programador que utiliza el enfoque tradicional puede prestar atención a la corrección del código, corre el riesgo de no detectar todas las fallas del código. El programador que utiliza el método TDD trabaja en el código hasta que pasa la prueba, mediante la refactorización del código. Esto se hace hasta que el código cumple con la funcionalidad, un proceso que probablemente resulte en menos errores.
¿Es TDD más lento o más rápido que el desarrollo tradicional de pruebas?
En cuanto a si TDD hace que el proceso de programación avance más rápido, existen estadísticas contradictorias de varias fuentes.
Un estudio de caso que involucra a equipos de ingenieros de software de Microsoft e IBM concluyó que “los equipos experimentaron un aumento del 15-35% en el tiempo de desarrollo inicial” cuando utilizaron la técnica TDD. Sin embargo, el estudio señala que estos son números "estimados subjetivamente por la gerencia” (Fuente).
Visto desde la perspectiva de que los estudios de Microsoft e IBM indican que hubo mejoras en la calidad, se puede argumentar que, a largo plazo, TDD ahorra el tiempo que se habría requerido para corregir problemas. Los equipos, tanto de Microsoft como de IBM, estuvieron de acuerdo con esta visión (Fuente).
Un estudio enfocado en las percepciones iniciales de profesionales experimentados al usar TDD concluye que “después de superar las dificultades iniciales para entender por dónde empezar y saber cómo crear una prueba para una funcionalidad que aún no existe, los participantes adquieren mayor confianza para implementar nuevas funcionalidades y realizar cambios debido a la amplia cobertura de pruebas” (Fuente). Esto parece indicar que la situación mejora con el tiempo.
Escribiendo para la plataforma de publicación online Medium.com, el programador y autor de “Composing Software” y “Programming JavaScript Applications”, Erick Elliot se enfoca en cómo TDD cambió su vida. Elliot reconoce que el proceso puede ser lento al principio, pero dice: “en algún punto alrededor de los 2 años, empezó a ocurrir algo mágico: empecé a programar más rápido con pruebas unitarias de lo que nunca lo había hecho sin ellas” (Fuente).
Parece que utilizar TDD puede hacer que todo sea más lento al principio. Sin embargo, si se ve desde una perspectiva a largo plazo, el tiempo ahorrado gracias a un código de mejor calidad puede compensar el tiempo invertido al inicio. Además, se puede esperar que, a medida que los programadores mejoran en TDD, tiendan a avanzar más rápido.
También hay muchos otros factores a considerar al tratar de medir el tiempo que toma obtener un resultado de alta calidad. Para más información al respecto, escucha el episodio de Niall Lynch en el pódcast The QA Lead sobre cómo medir T2Q (Time To Quality).
¿TDD produce menos errores?
En la discusión anterior, una de las principales ventajas que se le atribuye a TDD es que produce menos errores. Pero, ¿están de acuerdo las estadísticas?
Los mismos estudios que involucraron a los equipos de ingeniería de Microsoft e IBM concluyeron que “la densidad de defectos antes del lanzamiento de los cuatro productos disminuyó entre un 40% y un 90% en relación con proyectos similares que no usaron la práctica TDD”. Específicamente, los equipos de IBM reportaron una caída del 40% en la densidad de defectos y los de Microsoft informaron una disminución del 60-90% (Fuente).
¿Las estadísticas de Test Driven Development respaldan la conclusión de que TDD produce mejor calidad?
Con base en los resultados de un estudio presentado en el Primer Simposio Internacional de IEEE en Finlandia en 2007, Maria Siniaalto y Pekka Abrahamsson informan que se ha demostrado que TDD produce una mejor calidad de código en comparación con el software desarrollado sin TDD (Fuente).
En su artículo, Siniaalto y Abrahamsson citan un estudio realizado en China que concluyó que TDD mejoró el seguimiento de procesos y la estimación de tareas. El mismo estudio concluye que "TDD también mejora el seguimiento de prácticas y directrices consistentes". Esto resulta en una mejor calidad con menos defectos. Además, los equipos que utilizaron TDD pudieron corregir sus defectos más rápidamente (Fuente).
Un estudio realizado entre desarrolladores, con unos diez años de experiencia profesional (en promedio), para investigar sus percepciones al emplear TDD, cita a un desarrollador que dice: "TDD me ha ayudado a mejorar el código, haciéndolo más legible". Otro participante informa que "TDD permite una mayor mantenibilidad" (Fuente).
¿Promueve TDD un diseño más simple?
Boby George y Laurie Williams, ambos trabajando en el Departamento de Informática de la Universidad Estatal de Carolina del Norte, realizaron un experimento donde 24 programadores se dividieron en dos grupos: uno usó TDD y el otro el enfoque lineal.
George y Williams informan que entre los participantes, "el 92% de los desarrolladores creían que TDD produce un código de mayor calidad, el 79% pensaba que TDD promueve un diseño más simple y el 71% consideraba que el enfoque era notablemente efectivo" (Fuente).
Estas estadísticas de desarrollo guiado por pruebas sobre la calidad indican claramente que TDD, de hecho, resulta en un código de mayor calidad y un diseño más simple.
En un artículo publicado por el portal de aprendizaje gratuito Guru99.com, Kanchan Kulkarni dice: "TDD hace que el código sea más simple y claro. Permite al desarrollador mantener menos documentación" (Fuente).
¿Es fácil adoptar el diseño TDD?
Del experimento de George y Williams, el 56% de los desarrolladores profesionales creían que era difícil adoptar una mentalidad TDD, mientras que el 23% afirma que la falta de una fase de diseño inicial es la razón de esta dificultad. Del total de respuestas, el 40% consideró que la adopción de TDD es difícil (Fuente).
Estas estadísticas de desarrollo guiado por pruebas sobre la adopción señalan que TDD es percibido como difícil de adoptar.
¿Está sobrevalorado TDD?
En un artículo publicado en Medium.com, Tylor Borgeson, quien se autodenomina Desarrollador de Software Full Stack interesado en Machine Learning, IA, Infraestructura, DevOps y Agile, usa el titular "Test-Driven Development is Overrated". Sin embargo, el hecho de que haya puesto el título entre comillas muestra que no es una afirmación que él haga.
Borgeson luego se dirige a quienes dicen que el método está sobrevalorado y es lento, diciéndoles que la mayoría de las personas que sostienen esta opinión no han usado el método el tiempo suficiente. Al final de su artículo, dice: "Ahora practica el desarrollo guiado por pruebas hasta que ya no te duela" (Fuente).
¿Qué sigue?
Aprende enfoques de QA de expertos en el pódcast The QA Lead
Regístrate en el boletín de The QA Lead para recibir nuestras últimas guías prácticas y episodios del pódcast
Únete a la lista de espera del foro de la comunidad en línea de The QA Lead donde podrás compartir mejores prácticas con otros profesionales de QA y pruebas de software.
¡Espero verte allí!
