TDD - Desarrollo guiado por pruebas

El desarrollo guiado por pruebas o TDD es una práctica algo controvertida, ya que algunos sostienen que es esencial, mientras que otros argumentan que requiere demasiado esfuerzo y tiempo, y que no compensa. 

Si has experimentado con TDD, probablemente tengas tu propia opinión sobre su uso y aquí encontrarás muchos temas para ampliar tus conocimientos y habilidades. Si, por el contrario, no estás familiarizado con esta práctica, esta será tu guía de inicio.

Hemos recopilado contenidos útiles  para que te adentres en el mundo del TDD y  aprendas buenas prácticas para sacarle el máximo provecho en tus proyectos.

Queremos responder algunas preguntas habituales como: ¿TDD es realmente necesario? ¿Qué aporta a mis proyectos? ¿Sirve como metodología de diseño? ¿Cómo mejorar mis habilidades en TDD? Vas a encontrar respuestas sea cual sea tu nivel de experiencia con esta práctica.

¿Por qué usar TDD?

En Codurance consideramos que el TDD es una práctica que, aplicada correctamente, aporta agilidad a los procesos de desarrollo de software, contribuye a construir un código más fiable y flexible, y promueve soluciones de calidad escalables gracias a la automatización de los procesos. En esta sección recorremos las razones porque consideramos que TDD te ayudará a aumentar la calidad de tu código. 

¿Qué es TDD y para qué sirve?

TDD, o Desarrollo Dirigido por Pruebas (Test-Driven Development en inglés), es una metodología de desarrollo de software que enfatiza la escritura de pruebas automatizadas antes de escribir el código.

En líneas generales consiste en plantear una hipótesis sobre un comportamiento del sistema que queremos desarrollar  y luego corroborar esa hipótesis o comportamiento con el código que se está escribiendo. Siempre tratando que el código que valida la hipótesis sea el mínimo posible para validarla y así evitar caer en sobre ingeniería.

El proceso de TDD consiste en iteraciones sobre un ciclo de tres etapas: Red-Green-Refactor. En cada iteración se aborda una nueva hipótesis sobre el comportamiento que deseamos en el sistema. Veamos en qué consiste cada etapa de un ciclo: 

Red (Rojo): Se escribe un test automatizado para una nueva funcionalidad que falla inicialmente, ya que la funcionalidad aún no se ha implementado. Este paso garantiza que el test es válido, es decir que falla porque el comportamiento deseado no está implementado, y necesita la nueva funcionalidad para pasar.

Green (Verde): Se escribe el código mínimo necesario para que el test pase. Este paso se centra en hacer que el test pase lo más rápido posible, sin detenerse en la perfección del código.

Refactor (Refactorización): Una vez superado el test, el código se ajusta para mejorar su estructura y calidad, mientras los tests siguen funcionando. Esto puede incluir eliminar redundancias, mejorar la legibilidad y aplicar principios de diseño de software.

Las 3 leyes del TDD

1. No puedes escribir código de producción sin antes hacer un test fallido.
2. No puedes escribir más de un único test unitario, con el suficiente código para hacerlo fallar (error de compilación es fallo).
3. Solo puedes escribir código de producción para hacer pasar el único test fallido.

¿Cuáles son los beneficios de utilizar TDD?

TDD es una metodología poderosa para desarrollar software de alta calidad de una manera iterativa y sistemática, fomentando un mejor diseño del software y reduciendo los errores desde las etapas tempranas del desarrollo.

Beneficios del TDD a nivel técnico

• Mejora la calidad del software. Aumenta la fiabilidad del código y permite realizar cambios en el sistema con mayor facilidad y confianza.
• Fomenta un desarrollo ágil. Aunque inicialmente pueda parecer que el TDD ralentiza el proceso de desarrollo, a largo plazo puede hacerlo más eficiente al reducir el tiempo dedicado a depurar y corregir errores.
• Contribuye a un mejor diseño del software, más completo y mantenible, siempre que se sepa cómo luce un buen diseño.
• Genera cobertura contra regresiones (red de seguridad).
• Se alinea con una cultura de QA ya que el código que se escribe está pensado para ser testeado.
• Aporta estructura al proceso de desarrollo.
• Reduce los feedback loops, lo cual permite desplegar nuestro código de forma más rápida y segura.

Beneficios del TDD para el negocio

• Favorece la reducción de costes a largo plazo asociados a la depuración continua de errores.
• Reduce los riesgos asociados al mantenimiento y la escalabilidad del software. Un código bien diseñado y probado es más fácil de mantener y escalar.
• Aumenta la satisfacción y fidelidad de los clientes gracias a una mayor calidad del producto.
• Acelera el Time to Market de nuevos lanzamientos y productos al facilitar la integración y entrega continuas (CI/CD), lo que permite entregas más frecuentes.
• Eleva técnicamente el nivel del equipo y contribuye a la retención del talento.
• Reduce la barrera de entrada de nuevos desarrolladores/ras ya que los tests describen el comportamiento esperado (documentación viva).

Desafíos al adoptar TDD 

TDD y Software Craftsmanship

¿Cómo mejora TDD la calidad del software?

El Desarrollo Dirigido por Pruebas (TDD) mejora la calidad del software a través de varios mecanismos fundamentales. Estos principios no solo afectan la calidad del código desde una perspectiva técnica, sino que también influyen en el proceso de desarrollo de software, asegurando que el producto final sea más robusto, fiable y mantenible. 

Al escribir tests antes de implementar el código funcional, TDD reduce la probabilidad de introducir defectos en el código desde el principio. Esto se debe a que los criterios de éxito de una función se definen antes de implementarla, lo que reduce la ambigüedad y mejora la precisión de los requisitos del software. 

Las pruebas sirven como una red de seguridad que permite al equipo de desarrollo realizar cambios o refactorizaciones en el código con la confianza de que cualquier regresión o error introducido será capturado rápidamente por los tests existentes.

El TDD fomenta un enfoque iterativo e incremental, en el que la funcionalidad se construye y se prueba en pequeños incrementos. Así se garantiza que cada parte del sistema se implemente y pruebe correctamente antes de seguir adelante, reduciendo la complejidad y los riesgos asociados al desarrollo de grandes bloques.

Asimismo, los tests actúan como una forma de documentación viva que describe cómo se supone que debe comportarse el software. Esto es especialmente útil tanto para el mantenimiento del sistema como para la incorporación de nuevos desarrolladores/ras, ya que pueden comprender rápidamente las intenciones del código consultando los tests.

¿Cómo convencer a mi empresa de aplicar TDD?

Convencer a tu empresa para adoptar TDD implica presentar argumentos sólidos que destaquen los beneficios a largo plazo de esta metodología, así como abordar posibles preocupaciones sobre la inversión inicial en tiempo y recursos. Te presentamos algunos puntos clave que puedes utilizar para construir tu caso. 

1. Resalta los beneficios comerciales. Destaca cómo la inversión inicial en TDD puede suponer un ahorro a largo plazo al reducir los costes de desarrollo y mantenimiento gracias a la detección precoz de errores. También resalta que TDD puede dar a la empresa una ventaja competitiva al permitir una respuesta más rápida a las demandas del mercado gracias a un código más modular y flexible que facilita la implementación de cambios y nuevas funciones.

2. Aborda las preocupaciones sobre el tiempo y el coste. Reconoce que adoptar TDD requerirá tiempo y posiblemente formación para el equipo, pero argumenta que se trata de inversiones en la calidad y sostenibilidad del software. El resultado será un producto más estable y fiable y mejorará la satisfacción del cliente y la reputación de la empresa.

3. Presenta casos de estudio. Busca ejemplos de otras empresas, especialmente aquellas en la misma industria o de tamaño similar, que hayan adoptado TDD con éxito. Presentar resultados tangibles y testimonios puede ser muy convincente.

4. Ofrece sugerencias de formación y recursos. Propón recursos para el aprendizaje del equipo, como cursos o sesiones de pair programming con expertos en TDD. Mostrar que existe un plan claro para el desarrollo de habilidades puede aliviar las preocupaciones sobre la curva de aprendizaje.

5. Propón un plan de implementación gradual. Presenta una propuesta para adoptar el TDD gradualmente, empezando con un proyecto piloto o un pequeño equipo. Esto permite evaluar las ventajas del TDD con un riesgo mínimo y ofrece la oportunidad de aprender y realizar ajustes antes de una implantación más amplia.

6. Medir y compartir los progresos. Presenta métricas específicas para evaluar el impacto de TDD, como la reducción del número de errores notificados, la mejora del tiempo de desarrollo de nuevas funciones o la disminución del tiempo de depuración. Comprométete a medir y compartir estos resultados regularmente para demostrar el valor de TDD.

¿Cómo implementar TDD?

Como hemos explicado en la sección anterior, el Desarrollo Dirigido por Pruebas (TDD) implica la adopción de un enfoque cíclico y sistemático del desarrollo de software, en el que los tests guían la construcción del código. También hay que tener en cuenta que requiere un cambio en la mentalidad y cultura del equipo.

Pero, una vez que hemos considerado sus beneficios y retos y queremos empezar a aplicarlo, surge la pregunta: ¿por dónde empezar? La respuesta inmediata es que para iniciar se necesita una combinación de capacitación, formación y mucha práctica.

 En esta sección examinamos las mejores prácticas de TDD, algunos temas de debate, herramientas que pueden ayudar a su aplicación y antipatrones que conviene evitar.

Mejores prácticas de TDD

La implementación exitosa del TDD depende de seguir buenas prácticas que aseguren la eficacia del proceso y la calidad del software desarrollado. Aquí tienes un listado con las mejores prácticas recomendadas para TDD.

• Tests pequeños y focalizados. Cada test debe centrarse en un único aspecto o funcionalidad. Esto hace que los tests sean más fáciles de escribir, entender y mantener. 
  
  
• Claridad y limpieza. Loa tests deben ser claras y legibles, actuando como documentación viva del sistema. Deben explicar el propósito y el uso esperado de las unidades de código para la comprensión y el mantenimiento a largo plazo.
  
  
• Denominación de los tests. Los nombres de los tests deben ser descriptivos y reflejar lo que están probando. Esto puede ayudar a otros a entender el propósito de la prueba y qué aspecto del código se está validando.
  
  
• Refactorización. La refactorización no se aplica solo al código de producción; los tests también deben ser objeto de refactorización para mejorar su claridad y eficiencia.
  
  
• Frecuencia. Los tests deben ejecutarse tan a menudo como sea posible, idealmente de forma automática mediante la integración continua, para proporcionar retroalimentación rápida sobre los cambios en el código.
  
  
• Tests independientes. Cada test debe ser independiente y no depender de otros. Esto asegura que pueden ejecutarse en cualquier orden y que el fallo de un test no afecta a los demás. Por ello, es conveniente ejecutar todos los tests cuando se añade un comportamiento nuevo (en la fase Green) porque pasar (green) el último test no significa que no existe un error en otra parte. De esta manera nos aseguramos que no se ha introducido ningún error de regresión.
  
  
• Sencillez. Los tests deben ser simples y evitar contener lógica condicional o bucles, ya que esto puede introducir errores en los propios tests y hacerlos más difíciles de comprender y mantener.
  
  
• Disciplina. Mantenerse fiel al ciclo de TDD (Red, Green, Refactor) y resistir la tentación de saltarse pasos o escribir código sin una prueba fallida previa. Esto asegura que el proceso de TDD se mantenga efectivo.
  
  
• Pair programming. Implementar TDD en parejas te ayuda a obtener feedback inmediato sobre los tests y su comportamiento. Al aplicar pair programming mejorarás tus capacidades gracias al intercambio positivo y constructivo de ideas.

TDD como metodología de diseño de software

La relación entre TDD y el diseño de software es sin duda una de las cuestiones que genera más debate entre los profesionales del sector. Quién mejor para reflexionar sobre este tema que Sandro Mancuso, autor de The Software Craftsman, pionero en Software Craftsmanship, y developer experimentado con más de 25 años en la industria.

En los siguientes textos, Mancuso plantea preguntas que cualquier desarrollador/a (principiante o experimentado) se ha hecho a lo largo de su carrera, y además da una vuelta de rosca al concepto gracias a su dilatada experiencia y genera dudas que, a través de la práctica, te permitirán sacar tus propias conclusiones.

Estilos de TDD: Escuelas de Chicago y Londres

Entre los estilos de TDD más practicados se encuentran la Escuela de Chicago y la Escuela de Londres. Cada uno tiene sus propias particularidades, centrándose en diferentes aspectos del desarrollo de software y en cómo deben concebirse los tests.

Estos estilos se popularizaron a partir de una serie de vídeos en los que Bob Martin (Chicago) y Sandro Mancuso (Londres) comparan el desarrollo de una aplicación utilizando los dos enfoques.

Escuela de Chicago. También conocido como estilo clásico o tradicional, propone un enfoque de adentro hacia afuera (inside-out)  y se centra en probar los comportamientos esperados del software desde las partes más internas, o  de dominio del sistema, hacia las capas exteriores donde se produce la interacción con los usuarios de nuestro software. 

• Ventajas: Es más directo y puede resultar más accesible para los nuevos practicantes de TDD. Se centra en que el código funcione correctamente desde el principio, priorizando la simplicidad en el diseño.
• Desafíos: Puede conducir a un diseño menos enfocado en la interfaz y más en la implementación, lo que a veces resulta en código menos modular y con acoplamiento más fuerte.

Escuela de Londres. También conocido como el estilo Mockist, propone un desarrollo de afuera hacia dentro (outside-in) y se centra en el diseño y la arquitectura desde las capas exteriores de la aplicación hasta las capas internas, que representan el dominio del software. En este tipo de desarrollos se utilizan mocks y stubs para simular las interacciones entre diferentes unidades de código, lo que permite centrarse en cómo interactúan las piezas del sistema entre sí, más que en sus comportamientos individuales.

En outside-in normalmente se habla de un doble ciclo: un primer test de aceptación con su ciclo, y luego los subsiguientes tests unitarios que se crean hasta pasar el de aceptación (cada uno con su ciclo red-green-refactor).

• Ventajas: Promueve un diseño modular y desacoplado, y es muy útil en sistemas complejos donde la interacción entre componentes es un aspecto crítico del diseño.
• Desafíos: Requiere una comprensión más profunda de los conceptos de diseño de software y puede dar lugar a una curva de aprendizaje más elevada.

Ambas escuelas ofrecen valiosas perspectivas sobre cómo enfocar el desarrollo de software de forma que se dé prioridad a la calidad, la sostenibilidad y la eficacia del proceso de desarrollo. La elección entre la Escuela de Chicago y la Escuela de Londres depende a menudo del tipo de proyecto, las preferencias del equipo de desarrollo y los objetivos específicos de calidad y diseño del software.

Infraestructura necesaria: TDD y pipelines

Herramientas para facilitar la implantación de TDD

Para facilitar la aplicación de TDD, es esencial disponer de un conjunto adecuado de herramientas que abarquen desde el entorno local del desarrollador/a hasta la integración y entrega continuas en el pipeline.

Tooling para el equipo de desarrollo

Su propósito es facilitar la escritura, ejecución y depuración de pruebas.

• Frameworks de tests unitarios: Herramientas como JUnit (Java), pytest (Python), y Jest o Mocha (JavaScript) permiten al equipo de desarrollo escribir y ejecutar test unitarios eficazmente. Estos frameworks ofrecen una amplia gama de funcionalidades para definir casos de prueba, aserciones y mocks.
  
  
• IDEs y plugins: Entornos de desarrollo integrados (IDEs) como IntelliJ IDEA, Visual Studio Code, y PyCharm, entre otros, a menudo vienen con plugins o extensiones que facilitan TDD. Estos pueden incluir integración con frameworks de pruebas, ejecución de tests con un clic, y visualización de resultados de tests directamente en el IDE.
  
  
• Herramientas de cobertura de código: Instrumentos como JaCoCo (Java), Coverage.py (Python), y Istanbul (JavaScript) ayudan a medir la cobertura de tests, proporcionando visibilidad sobre qué partes del código no están siendo probadas.

Tooling para el pipeline

Estas herramientas automatizan la ejecución de tets y otras tareas relacionadas con la calidad del código como parte de los pipelines de integración y entrega continua (CI/CD).

• Servidores de CI/CD: Jenkins, GitLab CI, GitHub Actions, y CircleCI son plataformas que pueden configurarse para construir pipelines de CI/CD. Permiten ejecutar automáticamente pruebas unitarias, de integración y otras pruebas cada vez que se hace push de código nuevo al repositorio.
  
  
• Herramientas de análisis de calidad de código: SonarQube y Codacy ofrecen análisis estático de código que se puede integrar en el pipeline, ayudando a identificar problemas de calidad, vulnerabilidades de seguridad y deuda técnica.

Servicios SaaS

Los servicios basados en la nube (Software as a Service, SaaS) ofrecen una infraestructura gestionada y escalable para la integración y entrega continua, así como para la colaboración en el desarrollo de software.

• Plataformas de CI/CD: Travis CI, CircleCI, y GitHub Actions (en la nube) proporcionan entornos de CI/CD totalmente gestionados que eliminan la necesidad de mantener servidores de CI internos. Estos servicios se integran con repositorios de código en GitHub, Bitbucket, etc., y facilitan la configuración de pipelines de tests y despliegue.
  
  
• Herramientas de revisión de código: GitHub, GitLab, y Bitbucket no solo alojan código, sino que también ofrecen funcionalidades para la revisión de código, pull requests y discusiones que son esenciales para el proceso de TDD.
  
  
• Plataformas de tests automatizados: Sauce Labs y BrowserStack permiten ejecutar pruebas de UI en navegadores y dispositivos móviles, lo que facilita la validación de apps web y móviles en entornos reales sin necesidad de infraestructuras propias.

Antipatrones que dificultan del TDD

Al desarrollar software es posible caer en errores comunes o malas prácticas que a menudo entorpecen nuestros procesos y nos hacen perder tiempo y energía. Estos hábitos equivocados en los que caemos repetidamente, por lo general sin darnos cuenta, son lo que podríamos llamar antipatrones. Si no aprendemos a identificarlos, es posible que nos alejen de nuestro objetivo: desarrollar software de calidad.

Desde hace algún tiempo, Matheus Marabesi, software craftsperson en Codurance, ha estado fascinado con los antipatrones de TDD. Esto le llevó en 2021 a enviar una encuesta, a nivel mundial, a cualquier persona interesada y/o utilizando TDD en su lugar de trabajo para recoger sus experiencias.

Los resultados de la encuesta ayudaron a dar forma a una serie con 6 capítulos en la que Matheus repasa la lista de los 22 antipatrones de TDD recopilada por James Carr. 

A través de workshops, katas y blogs Matheus, junto con varios compañeros craftspersons, ofrece claves para aprender a identificar los antipatrones y evitar caer en la trampa de ciertos tests que generan bases de código muy grandes y conducen a procesos de feedback lentos.

Posteriormente, la encuesta y los vídeos se convirtieron en la base de su nuevo y más recientemente actualizado (enero de 2024) eBook: Patrones comunes que dificultan el TDD: Un ensayo de profesionales. Puedes descargarlo de manera gratuita aquí y compartirlo en tu equipo para empezar a aplicar TDD.

Descarga el eBook de antipatrones de TDD y descubre cuáles son las trampas más comunes y cómo evitarlas.