Test Driven Development: construyamos únicamente lo necesario

Como muchos de vosotros habréis experimentado en diferentes ocasiones, uno de los clásicos problemas en los proyectos de desarrollo de software (y otros) es la gestión de los deseos y peticiones del cliente. De hecho, si habéis pasado por esta situación, os habréis preguntado lo siguiente: ¿Si el peticionario ha solicitado un producto con ciertos requisitos, por qué no somos capaces de entregar únicamente lo que ha pedido? O incluso podemos ir un paso más allá, ¿Por qué muchas veces no llegamos ni a lo que se ha solicitado?

Como bien sabréis, y visto desde la óptica del test, esto se acaba traduciendo en multitud de defectos en el producto, amén de disponer de un software que no cubre totalmente con la necesidad del mercado para la que ha sido requerido. Del mismo modo, es más fácil que deficiencias nacidas en la fase del diseño del sistema permanezcan en el software por un largo periodo de tiempo.

Sigamos por el enfoque de testing, y vayamos a dar otra vuelta de tuerca: suponiendo que nuestros casos de prueba están bien diseñados, nuestros defectos podrán asociarse a pruebas falladas. Es decir, nuestra suite de Test Cases nos puede permitir mapear el estado del sistema bajo test. Partiendo de aquí, ¿Por qué no desarrollamos nuestro sistema en pequeñas porciones funcionales con el objetivo de pasar correctamente los casos de prueba? Sin querer, con esta pregunta, acabamos de definir la esencia de Test Driven Development (TDD).

TDD es una técnica de diseño e implementación de software frecuentemente utilizada dentro de la metodología de desarrollo ágil eXtreme Programming (XP), y que consiste justamente en lo que ha sido mencionado en el párrafo anterior. Es decir, con TDD la fuente de la que bebe el desarrollador es el caso de prueba, de manera que se implementará una pequeña porción de código para pasar única y exclusivamente los test cases diseñados con anterioridad. No haremos más, ni tampoco menos. Una vez hayamos cumplido esta máxima, podremos pasar a repetir el mismo proceso una y otra vez, hasta que hayamos construido el sistema que deseábamos.

Como vemos, el enfoque tradicional de “escribir código, para más tarde diseñar y ejecutar casos de prueba que verifiquen el código” pasa a ser “escribir, primeramente, casos de prueba que deba pasar el código, para luego escribir el código que pase el test”. ¿Cuáles son las principales ventajas de utilizar TDD? Básicamente, podríamos mencionar las siguientes:

• Con TDD implementamos únicamente lo que se ha solicitado, ya que no se hará más que lo estrictamente necesario para pasar correctamente el juego de pruebas asociado a un código.
• Como consecuencia del punto anterior, con esta técnica de diseño se minimiza la aparición de errores en producción, ya que el programador dispone de una fuente de requisitos más estricta y menos dispersa. Por lo tanto, la calidad del sistema aumenta drásticamente, creciendo de manera moderada el tiempo invertido en desarrollo.
• Por norma general, el código generado usando TDD es de una mayor calidad técnica.
• La construcción de software en pequeños grupos funcionales, cumpliendo con los principios ágiles, facilitará que partes del software que está siendo desarrollado, puedan ser utilizadas en la construcción de otros sistemas.
• QA participa de la vida del desarrollo del sistema desde una etapa más temprana, aprovechando su conocimiento del producto y su mentalidad orientada a la calidad, lo que conducirá a la minimización de riesgos globales del proyecto.
• Y, como muchos habréis podido comprobar, los casos de prueba son muchas veces la documentación más fiable del sistema. Con TDD, todavía se enfatiza más en este punto.

No obstante, cabe remarcar que parte del éxito en el uso de esta técnica de desarrollo depende de los siguientes factores:

• El número de tests diseñados en cada iteración no debe ser muy amplio, ya que a mayor cantidad, más probabilidad de cometer errores. Por otro lado, el tamaño de cada uno de los casos debe ser razonable, para facilitar la comprensión al desarrollador.
• Los tests escritos no deben ser muy complejos, pero tampoco muy triviales, ya que estos podrían obviar detalles relevantes para el diseño del sistema.
• Los casos de prueba deben describir fidedignamente el comportamiento deseado del sistema.
• Toda la organización debe adoptar prácticas de desarrollo acordes a la metodología TDD. De nada nos vale una adopción parcial de la técnica.

Por todo este seguido de ventajas es relativamente posible, que en un momento u otro, muchas organizaciones se planteen la utilización de TDD, siendo un paradigma muy fiable a la hora de construir sistemas complejos y con una alta calidad de desarrollo.

Si quieres conocer más sobre nuestras soluciones de calidad de software, visita nuestra web.

Isaac Álvarez Diz
QA Manager