Desarrollo guiado por pruebas para aumentar la calidad del software

Recomendados:  Aplicaciones, ¿cómo desarrollo, entrego y gestiono mi software?Webinar IT Trends 2021. Asimilando la aceleración digital Leer

En el proceso de desarrollo de software se suceden numerosas etapas y en muchas ocasiones se trabaja en paralelo en diferentes partes de la programación, un trabajo complejo que si no se lleva a cabo de forma rigurosa y coordinada genera errores y retrasos en los proyectos. Para minimizar los fallos y garantizar la calidad del resultado es fundamental comprobar el código y el funcionamiento de cada desarrollo, algo que en muchos casos se realiza como un proceso independiente, posterior a la programación. Pero está surgiendo una nueva metodología denominada Test-Driven Development (TDD), que se basa en convertir los requisitos de un proyecto de desarrollo en casos de prueba. Si, al someterlos a un test, generan errores, se aplica la refactorización para limpiar el código o mejorar la implementación, lo que ofrece muchas ventajas de cara al resultaod final.

La firma latinoamericana de préstamos y soluciones de consumo Creditas ha analizado las características de la metodología de desarrollo guiado por pruebas para demostrar su valor a la hora de crear aplicaciones más robustas, fiables y seguras, tanto a nivel interno de la empresa como para los clientes. En este informe TDD señalan que esta forma de plantear un proyecto de desarrollo aporta muchas ventajas frente a los enfoques de pruebas tradicionales. Explican que una vez que se ha generado el código los equipos de desarrollo generalmente llevan a cabo test unitarios, test de integración, de rendimiento o de aceptación. Estos se realizan con herramientas manuales o automatizadas y sirven para identificar errores, lagunas o nuevos requisitos, pero esta forma de trabajar no garantiza un estándar de calidad adecuado.

En cambio, los proyectos realizados en base a TDD permiten identificar posibles errores de forma anticipada, dan como resultado un código mejor diseñado, más limpio y escalable y ayudan a comprender mejor cómo se utilizará este código. Además, proporcionan más confianza a la hora de refactorizar el código que se está implementando, facilitan el trabajo en equipo con técnicas como Ping Pong y ahorran mucho tiempo de depuración al proporcionar un software más acotado.

Todas estas ventajas están convenciendo cada vez más a las comunidades de desarrolladores, pero todavía quedan mucho que no han adoptado la metodología TDD, por diversos motivos. Como explica Kevin Sotomayor, ingeniero de software de Creditas, “en muchas ocasiones, los equipos no adoptan el TDD por falta de tiempo y/o entrenamiento previo en esta técnica de desarrollo. Además, un desarrollo basado en pruebas puede parecer más lento, aunque en realidad acaba aportando más valor al proceso por muchas razones”. Afirma que las ventajas que ofrece van más allá del propio proyecto en el que se aplica, ya que se genera documentación valiosa para los desarrolladores a la hora de abordar otros trabajos similares, y a medida que se utiliza esta técnica aumenta su valor.

Miguel Alberto García, ingeniero de software de Creditas comenta que “no hay una guía estricta de cuándo aplicar el TDD y cuándo no. Depende mucho de la capa a testear del software, de la cultura organizativa, del grado de madurez del equipo, del expertise del desarrollador, de si se está o no definiendo una arquitectura o desarrollando una funcionalidad…” como ejemplo, dice que “en Creditas, el uso de TDD es una metodología de desarrollo y diseño considerada como parte fundamental de nuestro trabajo diario”.

Aunque puntualiza que adoptar la metodología de desarrollo guiado por pruebas requiere mucho tiempo de aprendizaje en un principio, ya que implica cambios profundos en la planificación del proyecto y del trabajo de programación y prueba. Pero a medida que se adquiere experiencia se reduce el tiempo extra que se dedica a los proyectos, y los beneficios superan a las desventajas desde el principio. Porque, a pesar de introducir más procesos de planteamiento inicial y pruebas a lo largo del trabajo, el resultado es muy superior de cara al cliente, ya que se logra un software con menos defectos y más fácil de mantener.

Sotomayor afirma que “es quien construye el código, quien hace que el TDD funcione. Hay que comprender que las pruebas son parte del sistema, que deben diseñarse y que el código de prueba evoluciona hacia algo más específico, mientras que el código de producción evoluciona hacia algo más genérico”. Por ello, en Creditas consideran que, si no se emplean principios de diseño para hacer evolucionar el código y no se mejoran las pruebas junto al código, ambos irán en direcciones diferentes y empeorarán los resultados.