Beneficios del Desarrollo Guiado por Pruebas: Estadísticas y Estudios Clave
En este artículo, reviso algunas estadísticas y estudios sobre el desarrollo guiado por pruebas para entender cómo se ha implementado, los beneficios y los desafíos que enfrentan los equipos con este enfoque.
Tradicionalmente, el proceso de desarrollo de software procede de manera lineal. Sin embargo, en las últimas décadas, a medida que los sistemas ágiles se vuelven más populares (hasta un 87 % de los equipos siguen un enfoque ágil o similar), el desarrollo de software ha empezado a adoptar diferentes metodologías que tienen 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 llamando la atención en el ámbito del desarrollo ágil de software.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
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 “Test-Driven Development (TDD) es una de las prácticas fundamentales del proceso de desarrollo Extreme Programming (XP)” (Fuente).
Se informa que el hombre al que se le atribuye el desarrollo de TDD “afirmó en 2003 que TDD fomenta diseños simples e inspira confianza” (Fuente). Sin embargo, siguen existiendo preguntas sobre las afirmaciones relativas a la productividad y calidad atribuida al TDD.
Nos tomamos un tiempo para recopilar las estadísticas más recientes sobre TDD para comprobar las afirmaciones realizadas.
Este artículo comienza definiendo el concepto de TDD y cómo difiere del enfoque tradicional. Luego analizamos algunas de las estadísticas que validan o rechazan las afirmaciones hechas sobre el 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 necesario para cumplir con dicha prueba. La idea básica de esta técnica es permitir que quien escribe el código se tome un tiempo para considerar su diseño o requisitos antes de redactar el código funcional.
Proceso TDD
- Redacción de la prueba: En TDD, todas las nuevas funcionalidades empiezan con la redacción de una prueba. El programador debe comprender la especificación y los requisitos de la función. Para lograr esto, necesitarán revisar historias de usuario y casos de uso para entender el objetivo del nuevo código que están desarrollando.
- La prueba falla: Una vez que el programador ha escrito la prueba, la ejecuta. Debido a que aún no existe el 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. Puede que el código no sea perfecto o que no pase la prueba con excelencia, pero eso no importa. Al desarrollador no se le exige escribir código más allá de la funcionalidad para la que se creó la prueba.
- Ejecutar pruebas: Sabiendo que la funcionalidad funciona tal como fue diseñada, cada vez que liberen nuevo código, el programador puede usar una herramienta de gestión de pruebas para ejecutar esa prueba nuevamente, lo que le proporciona 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 limpiarse continuamente. 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 conservan sus características externas. Esta fase puede eliminar duplicados y agregar nuevas funcionalidades.
- Repetir: Los pasos anteriores se repiten automáticamente para asegurar que los ciclos de TDD cubren todas las funcionalidades.
Diferencias entre TDD y el desarrollo tradicional
Para comprender TDD, parece apropiado determinar en qué se diferencia de los enfoques tradicionales de programación.
La principal diferencia es que los métodos tradicionales siguen un proceso lineal, mientras que el TDD pasa por un proceso cíclico.
Los programadores que utilizan los métodos tradicionales de pruebas comienzan creando el código y sólo 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 cumple con esa prueba. Este enfoque comparte muchos principios del 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 usa el método TDD trabaja en el código hasta que pasa la prueba, realizando refactorización en el código. Esto se hace hasta que el código cumple con la funcionalidad, lo que probablemente resulta en menos errores.
¿Es TDD más lento o más rápido que el desarrollo de pruebas tradicional?
En lo referente a si TDD hace que el proceso de programación sea más rápido, existen estadísticas contradictorias de diversas fuentes.
Un estudio de caso con 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 usaron la técnica TDD. Sin embargo, el estudio señala que estos son números “estimados subjetivamente por la dirección” (Fuente).
Si se observa 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 habría sido necesario para corregir problemas. Los equipos, tanto de Microsoft como de IBM, estuvieron de acuerdo con esta opinión (Fuente).
Un estudio enfocado en las percepciones iniciales de profesionales experimentados al utilizar TDD concluye que “después de superar las dificultades iniciales para entender por dónde empezar y cómo crear una prueba para una funcionalidad que aún no existe, los participantes ganan mayor confianza para implementar nuevas características y realizar cambios gracias a una amplia cobertura de pruebas” (Fuente). Esto sugiere que con el tiempo, la situación mejora.
Escribiendo para la plataforma de publicaciones en línea 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 está de acuerdo en que el proceso puede ser lento al principio, pero dice: “alrededor del plazo de 2 años, algo mágico comenzó a suceder: empecé a programar más rápido con pruebas unitarias que nunca antes sin ellas” (Fuente).
Parece que usar TDD puede hacer las cosas más lentas al principio. Sin embargo, si se observa desde una perspectiva a largo plazo, el tiempo ahorrado gracias a la mejor calidad del código puede compensar el tiempo perdido al inicio. Además, se puede esperar que a medida que los programadores mejoran en TDD, es probable que trabajen más rápido.
También hay muchos otros factores a considerar al tratar de medir el tiempo que lleva obtener un resultado de alta calidad. Para más sobre este tema, escucha el episodio de Niall Lynch en The QA Lead podcast sobre cómo medir el T2Q (Time To Quality).
¿El TDD resulta en menos errores?
En la discusión anterior, una de las principales ventajas que se presentan del TDD es que resulta en 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 arriba concluyeron que “la densidad de defectos pre-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 reportaron una caída del 60-90% (Fuente).
¿Las estadísticas de Desarrollo Guiado por Pruebas respaldan la conclusión de que TDD produce mejor calidad?
Basado 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 mejor calidad de código en comparación con 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 los procesos y la estimación de tareas. El mismo estudio concluye que “TDD también mejora el cumplimiento de prácticas y directrices coherentes”. Esto da como resultado una mejor calidad con menos defectos. Además, los equipos que usaron TDD pudieron solucionar 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, recoge el testimonio de un desarrollador que afirma: “TDD me ha ayudado a mejorar el código, haciéndolo más legible.” Otro participante señala que “TDD permite una mayor mantenibilidad” (Fuente).
¿TDD promueve un diseño más simple?
Boby George y Laurie Williams, ambos trabajando en el Departamento de Ciencias de la Computación de la Universidad Estatal de Carolina del Norte, realizaron un experimento donde 24 programadores fueron divididos en dos grupos: uno usó TDD y el otro el enfoque lineal.
George y Williams informan que, de los participantes, “El 92% de los desarrolladores creyó que TDD produce código de mayor calidad, el 79% pensó que TDD promueve un diseño más simple y el 71% consideró que el enfoque era notablemente efectivo” (Fuente).
Estas estadísticas sobre desarrollo guiado por pruebas acerca de la calidad indican de forma contundente 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 gratuito Guru99.com, Kanchan Kulkarni afirma: “TDD hace que el código sea más sencillo y claro. Permite al desarrollador mantener menos documentación” (Fuente).
¿Es fácil adoptar el diseño TDD?
Según el experimento de George y Williams, el 56% de los desarrolladores profesionales consideró que era difícil adoptar la mentalidad de TDD, mientras que el 23% afirma que la razón de esta dificultad es la falta de una fase de diseño inicial. Del total de respuestas, el 40% creyó que la adopción de TDD es difícil (Fuente).
Estas estadísticas sobre desarrollo guiado por pruebas en cuanto a adopción indican 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 Aprendizaje Automático, IA, Infraestructura, DevOps y Agile, utiliza el titular “Test-Driven Development is Overrated”. Sin embargo, el hecho de que coloque el titular entre comillas demuestra que no es una afirmación que él mantenga.
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 utilizado el método el tiempo suficiente. Para terminar su artículo, dice: “Ahora practica el desarrollo guiado por pruebas hasta que deje de doler” (Fuente).
¿Qué sigue?
Aprende enfoques de QA de expertos en el pódcast The QA Lead
Suscríbete al boletín de The QA Lead para recibir nuestras últimas guías paso a paso y episodios del pódcast
Únete a la lista de espera para el foro de la comunidad en línea The QA Lead donde podrás compartir buenas prácticas con otros profesionales de QA y pruebas de software.
¡Espero verte allí!
