TDD: Primero el test, luego el desarrollo

Max Lambrecht, líder de proyecto en Baires IT, enumera los beneficios de una de las metodologías más reconocidas a la hora de crear software. Aseguró que evita escribir código innecesario, reduce la cantidad de errores y le da más confianza a los programadores

El desarrollo de software no escapa a la realidad de buscar en forma permanente una mejor práctica para optimizar recursos y alcanzar buenos resultados en menor plazo. Aunque el sector IT crece en certificaciones, muchas empresas siguen viviendo un desconcierto interno al momento de poner manos a la obra. Max Lambrecht, líder de proyecto en Baires IT, muestra algunos de los beneficios de una de las metodologías más reconocidas en el mundo y que puede servir como modelo para el sector.

Los test automáticos de prueba o TDD, por su denominación en inglés (Test DrivenDevelopment), nacen de una reflexión que cambia radicalmente la ecuación de los programadores. Antes de su aparición, lo normal era escribir código y, al concluirlo, testear y detectar bugs. Esto no solamente era engorroso sino ineficiente.

La metodología TDD, por el contrario, consiste en realizar primero los tests y luego el código. Así es: primero se hace el test, después se desarrolla el código. “Nos vemos forzados por método a pensar una acción específica que debe realizar la aplicación, luego se desarrolla un test con el objetivo de probar que la aplicación realiza esa acción correctamente y, por último, se escribe el código para que pase ese test”, explicó Lambrecht.

Respecto a la evaluación de la puesta en práctica, comentó: “La experiencia usando TDD fue muy satisfactoria, porque evita escribir código innecesario, reduce la cantidad de errores y le da más confianza a los desarrolladores para hacer los refactorsnecesarios, mejorando así la calidad y mantenibilidad del código”.

Los defensores de la metodología hacen fundamentalmente hincapié en el ahorro de tiempo que, en términos de negocio, se traduce en dinero. Con la escasez y el costo del personal técnico, no es para menospreciar el hecho de que, según Lambrecht, el TDD “evita mucho trabajo al desarrollador, porque una vez que tiene los tests, sólo se ocupa de ejecutarlos y no vuelve a preocuparse por probar si su código funciona. Esta economía de tiempo es incluso más significativa en la fase de mantenimiento de los sistemas”.

Finalmente, el ejecutivo dejó una última razón para aplicar TDD en los departamentos de desarrollo, que “es quizás menos obvia, pero no menos importante. Al pensar en el test antes de implementar la funcionalidad, el desarrollador se ve forzado a analizar la interfaz y la usabilidad de la solución, lo cual suele redundar en un mejor diseño”.


Más información: www.bairesit.com.