21

Abr

Publicado por: Xavi Hidalgo | Agile Developments | Beneficios TDD | desarrollo | tdd | Test Driven Development

Beneficios del desarrollo de software TDD

Hace ya unos años trabajé en proyectos donde el código no estaba diseñado mediante Test Driven Development. Todos cometemos errores, pero al final siempre se saca algo positivo; aprendemos de los errores del pasado. Ahora lo tengo claro, he llegado a la conclusión que la mejor forma es hacer TDD.

Algunas veces surgen problemas de comunicación funcional con el equipo –como a todo el mundo-. Si no estoy pendiente de lo que voy haciendo puedo hacer incluso más de lo necesario para proporcionar un incremento realmente funcional al cliente final. Así pues, el TDD es recomendable para mejorar la productividad, ayuda a trabajar más rápido y generando menos “bugs” o errores.

¿Qué es TDD y cómo funciona?

Simplemente es una forma de escribir software. Es importante entender que, normalmente, este enfoque se usa en compañías regidas por principios “Agile”. La idea es: después de añadir una funcionalidad, crear un test automatizado sobre cómo debe comportarse esta nueva funcionalidad que se quiere introducir en tu sistema (un nuevo código). Luego se activa el test y esperas a que falle, sí, seguramente fallará. Después se actualiza de nuevo el código operativo con las especificaciones, escribes el código más simple para que lo pase. Activas el test otra vez y estás seguro que esta vez va a pasar. Finalmente debes refactorizar (incluso el código más simple tiene cualidades poco deseables) y asegurarte de tener un código “limpio”.

Proceso-TDD

14 razones para hacer TDD

  1. Evita el “overengineering”. Este es un problema común con el que se encuentran muchos desarrolladores. Como su nombre indica, significa se “hace de más”. Se refiere al hecho que no todas las piezas de código son necesarias para su funcionalidad específica. El TDD ayuda a los programadores a focalizarse exactamente en lo que necesitan construir… ¡Sin caer en el “overengineering”!
  2. El feedback de mi API. El TDD ayuda a tener una respuesta de la API mucho más rápida. Esta agilidad ayuda al diseño de la API porque no se necesita empezar el test desde el inicio, es un proceso acumulativo y no necesitas crear todas las capas. ¡Eso supone un ahorro de tiempo!
  3. Documentación amplia. El TDD es la forma más efectiva de comunicar y sirve también para mantener un “registro” de lo que pensabas durante el desarrollo. Los métodos de testing proporcionan un dibujo claro sobre una función particular, que entra y que sale. Cuando te encuentras un código generado por terceros, vas directamente a analizar que hace el código y su responsabilidad en el conjunto del sistema.
  4. Diseño emergente. No se necesita saber exactamente que hará una clase o función. Por supuesto es mejor tener información, pero esto no significa que tu diseño estará suficiente maduro para responder bien a cambios. El proceso de refactorización se ocupa de desarrollar el diseño hasta el punto que debería.
  5. “Interface” independientes. Para evitar contaminar las decisiones de diseño sobre la API, mejor que conozcas el contrato. Sin esto, el poder de la programación “object-oriented” no existe. Estoy hablando de polimorfismo y modularidad, “I” de SOLID (segregación de interfície).
  6. Mejora la comunicación. El TDD ayuda a la comunicación entre compañeros, un problema que está pendiente de resolver.
  7. Da tranquilidad. El TDD te permite tocar cualquier proyecto sin miedo a hacerlo mal, sin miedo a que falle completamente.
  8. Refactorización. Este concepto consiste en cambiar fácilmente el diseño de tu aplicación sin cambiar su funcionalidad. Desde que la función está siento testada, hacer el TDD es la única forma de asegurar que después de cambiar el código todo funciona como antes. No he visto aún ninguna forma más rápida y segura.
  9. Debugging. El TDD es la mejor manera de arreglar los “bugs”. La primera cosa a hacer es el test para reproducir el error. Cuando está hecho, es más sencillo que el “bug” no se vuelva a producir porque tiene la cobertura del test.
  10. La escalabilidad funcional. A medida que la aplicación se vuelve más compleja, incrementa su coste y supone también alargar el “time-to-market”. Si no se hace el TDD, llegará un punto en que sería inviables mantener el código. La complejidad genera, además, falta de entendimiento de los componentes más complejos.
  11. Aprender. El TDD ayuda al equipo a mejorar. He observado a mi equipo trabajar conjuntamente en “testings” y les he visto crecer mucho.
  12. Satisfacción del cliente. No olvidar que siempre hay un propietario de producto o cliente esperando un resultado operativo y el TDD funciona.
  13. Desarrollo ágil. Con test automatizados, consigues un “feedback” rápido además de otros muchos beneficios; durante la construcción del proyecto vemos si la estructura se rompe en algún punto o no. Esto nos proporciona una implementación de integración continua exitosa. Esto supone que el coste de implantación para construir el proyecto se reduce a cero.
  14. Integración mejorada con partes de terceros. Cuando lo tienes todo bajo testeo, sufres menos para integrar partes de terceros. Fusionar es menos costos y requiere menos horas realizando el TDD.

Después de conocer estos datos, mucha gente quiere hacer TDD, pero argumentan que les es difícil el tiempo para hacerlo y otras excusas. ¿Qué respondo a esto? No pongas más excusar, ni te auto-engañes, deberías usar TDD cuanto antes. Un developer “senior” debe ser decisivo, a pesar que las condiciones sean difíciles. Si quieres ser más productivo, solamente… ¡Haz TDD!

¡Si te ha gustado este articulo y quieres estar al día con nuestras actualizaciones del blog puedes subscribirte a nuestra newsetter para conocer las noticias más recientes!

 

Barcelona
Passeig Gaiolà 13
+34 933 801 144
Lleida
Carrer Agustins 7
+34 973 988 222
Andorra
(Escaldes-Engordany)
Parc de la Mola 10, AD700
Bogota
Carrera 9A #99-07 Piso 9. Despacho 02
Torre la Equidad