¿Qué es el desarrollo basado en pruebas (TDD)?

Los desarrolladores escriben suficiente código para pasar cada prueba, luego tanto la prueba como el código se refinan antes de pasar a una nueva prueba y luego a una nueva característica.

El desarrollo basado en pruebas básicamente obliga a los desarrolladores a ralentizar, validar y refinar su código en ciclos de feedback más cortos. Si bien no es obligatorio, los equipos de DevOps animan a los programadores, desde principiantes hasta profesionales experimentados, a utilizar TDD en una amplia gama de lenguajes de programación. Por ejemplo, Java, Python, etc., interfaces de programación de aplicaciones (API) y aplicaciones de programas.

La programación en este estilo fortalece la relación entre la codificación, las pruebas (en forma de pruebas automatizadas a nivel de unidad) y el diseño de código. Si bien el desarrollo basado en pruebas puede aumentar el tiempo de desarrollo inicial, se ha demostrado que mejora la funcionalidad y la destreza del código y ahorra tiempo en general.

Al identificar y dirigirse inmediatamente a cualquier error, los desarrolladores que utilizan TDD pueden evitar que los pequeños problemas se conviertan en problemas mayores. El desarrollo basado en pruebas obliga a los desarrolladores a validar y perfeccionar su código sobre la marcha, lo que agiliza las comprobaciones y correcciones finales de calidad. 

Los marcos de pruebas alternativos incluyen escribir el código de producción antes de escribir todas las pruebas automatizadas o escribir todo el conjunto de pruebas antes de escribir el código de producción. Se ha demostrado que estos métodos, aunque no necesariamente ineficaces, aumentan los tiempos de depuración necesarios, especialmente con proyectos más grandes y complejos.

Aunque el desarrollo basado en pruebas se utiliza habitualmente para la creación de nuevo código de producción, también se aplica a menudo para mejorar la depuración de código heredado desarrollado con técnicas más antiguas o de otro tipo. 

El desarrollo basado en pruebas invierte el proceso de desarrollo tradicional al anteponer las pruebas al desarrollo. Como enfoque iterativo, el desarrollo basado en pruebas mejora la calidad y la legibilidad del código al promover flujos de trabajo comprobables que dan como resultado un código de alta calidad a nivel de unidad. Cuando los desarrolladores implementan pruebas unitarias, se centran en una pequeña parte de la lógica, como un algoritmo individual. Escribir código específicamente para que las pruebas pasen no solo da como resultado un código más limpio y duradero, sino que también ayuda a mejorar la documentación. 

Hay dos niveles principales de desarrollo basado en pruebas.

Para el TDD de aceptación, a veces llamado Desarrollo Guiado por el Comportamiento (BDD), los programadores escriben una única prueba de aceptación y luego suficiente código nuevo para pasarla. Las pruebas de aceptación se denominan a veces pruebas de cliente o pruebas de aceptación del cliente.

Por lo general, pueden entenderse como casos de prueba necesarios para una funcionalidad mínima según lo descrito por las partes interesadas del producto. El ATDD se esfuerza por identificar requisitos detallados y ejecutables. Las pruebas de aceptación se pueden realizar utilizando varias herramientas de prueba, como Fitnesse o RSpec.

A veces denominado simplemente TDD, el TDD para desarrolladores requiere que los programadores escriban pruebas individuales para evaluar su propia solución a una prueba ATDD. El desarrollador TDD utiliza herramientas de automatización de pruebas, como JUnit o VBUnit. 

Cuando se emplea una estrategia de desarrollo basada en pruebas, los programadores primero escriben pruebas para comprobar cada elemento o función individual de un software antes de escribir suficiente código para pasar esa prueba individual. Una vez completado, el software se vuelve a probar y, si pasa, el código se refina (un proceso conocido como refactorización) para incluir solo los elementos esenciales. A continuación, los desarrolladores repiten este proceso para cada función de software posterior. 

El proceso de desarrollo basado en pruebas se divide en cinco pasos individuales:

1. Antes de escribir el código para una determinada función de software, los desarrolladores primero escriben una prueba unitaria individual para esa función.
2. A continuación, ejecutan la prueba, que debería fallar porque la función de código aún no se ha escrito. Este paso es importante para confirmar que la prueba en sí es funcional y no devuelve ningún falso positivo. Si el código pasa, indica que la prueba debe reescribirse.
3. Cuando el programa no pasa la prueba, los desarrolladores escriben solo el código de software adicional suficiente para pasar la prueba. 
4. Cuando el código puede pasar la prueba, tanto la prueba como el código se refactorizan para simplificar y eliminar cualquier código innecesario. 
5. Cuando el software suficientemente refactorizado puede pasar la prueba de refactorización, los desarrolladores se mueven a la siguiente función de software deseada. A continuación, los evaluadores escriben y ejecutan pruebas para cada nueva característica. 

En pocas palabras, el proceso de desarrollo basado en pruebas sigue un bucle repetible, denominado ciclo rojo-verde-refactorizar. Los pasos del ciclo son:

• Rojo: escriba una prueba con errores para el comportamiento de software previsto. 

• Verde: escriba lo suficiente como para pasar la prueba.

• Refactorizar: refine el código para cumplir con los estándares de simplicidad tanto como sea posible sin dejar de pasar la prueba.

Si bien se desconocen los orígenes específicos del desarrollo basado en pruebas, el concepto de escribir primero las pruebas y después el código de producción no era una práctica común hasta mediados de la década de 1990. Antes de eso, los marcos de prueba separaban a los desarrolladores de probar sus propias bases de código. Sin embargo, a medida que la ingeniería de software evolucionó, los equipos de DevOps exigieron metodologías más rápidas y flexibles para satisfacer las demandas de las partes interesadas, especialmente cuando se trata de requisitos de las partes interesadas que cambian rápidamente. 

El desarrollo basado en pruebas evolucionó a partir de varios marcos de prueba novedosos y junto con ellos, y también se ha adoptado como un componente modular en otros marcos. En particular, el TDD está incluido en el concepto de Programación Extrema (XP), un marco de desarrollo de software ágil desarrollado para mejorar tanto la calidad del software como la calidad de vida de los desarrolladores.

Al ingeniero de software Kent Beck, una figura importante en la comunidad ágil y creador de Extreme Programming, se le atribuye el "redescubrimiento" del desarrollo basado en pruebas. En las propias palabras de Beck: 

"La descripción original del TDD estaba en un libro antiguo sobre programación. Decía que tomes la cinta de entrada, escribas manualmente lo que esperas en la cinta de salida y luego programes hasta que la cinta de salida real coincida con la salida esperada. Después de escribir el primer marco xUnit en Smalltalk, recordé haber leído esto y lo probé. Ese fue el origen del TDD para mí. Cuando describo el TDD a programadores mayores, a menudo escucho: "Por supuesto. ¿De qué otra manera podrías programar?" Por lo tanto, me refiero a mi papel como el de "redescubrir" el TDD". 

Las fechas notables en la evolución del desarrollo basado en pruebas incluyen:

• 1976: Glenford Myers publica Software Reliability, en el que argumenta que "un desarrollador nunca debe probar su propio código". Aunque Myers podría no haber sido el creador de este concepto, su trabajo dio crédito a una noción común que impregnaría los años venideros. 

• 1990: a principios de la década, la técnica de "caja negra" dominaba las pruebas de software. En este tipo de marco de pruebas, los evaluadores tratan el software como si fuera una "caja negra", impenetrable e incognoscible. Las pruebas de caja negra emplean probadores que, lo que es más importante, no tienen conocimiento del funcionamiento interno del software. 

• 1994: Kent Beck desarrolla SUnit, un marco de pruebas de Smalltalk, sentando las bases para un enfoque basado en las pruebas para la optimización de la base de código. 

• 1999-2002: a medida que el movimiento de desarrollo ágil cobra fuerza, Kent Beck desarrolla el concepto de programación extrema, codificando el desarrollo dirigido por pruebas e introduciendo el concepto crítico de objetos simulados. El TDD utiliza objetos simulados para simular los comportamientos de dependencias reales (por ejemplo, bases de datos, servicios externos, etc.) durante las pruebas. Este método ayuda a los desarrolladores a centrar su código de prueba en objetos simulados mantenibles cuyo rendimiento pueda verificarse con precisión. Una prueba fallida que utiliza un objeto simulado puede eliminar una dependencia potencialmente mal configurada como fuente de la falla. 

• 2003: Kent Beck publica Test Driven Development: By Example, que populariza la práctica entre la comunidad de desarrollo en general y legitima aún más las pruebas impulsadas por los desarrolladores. 

Como componente de la programación extrema, se ha descubierto que el desarrollo basado en pruebas es beneficioso no solo para crear un código mejor, sino también para mejorar a los propios codificadores. El TDD puede permitir a los codificadores obtener un mejor conocimiento de sus proyectos y ayudar a impulsar el diseño del programa. Al centrar el caso de prueba antes de implementar cada característica, los desarrolladores deben visualizar cómo utilizará una función un cliente o usuario. Este enfoque sitúa la interfaz del producto antes de la implementación y ayuda a los desarrolladores a crear aplicaciones más centradas en el usuario. 

Algunos beneficios adicionales del desarrollo basado en pruebas incluyen:

• Cobertura integral de pruebas: a veces se hace referencia al TDD como una herramienta de especificación o documentación porque la práctica garantiza que todo el código esté cubierto por al menos una prueba. 

• Documentación mejorada: por la misma razón que el TDD proporciona una cobertura completa, también proporciona documentación y especificaciones sólidas. Este sistema ayuda a los desarrolladores, gestores de proyectos y otras partes interesadas a validar las características y requisitos del código y a establecer el orden a lo largo del ciclo de vida del proyecto. 

• Mayor confianza: los desarrolladores y los equipos de DevOps que utilizan TDD consiguen una mayor confianza no solo en su código, sino también en sus pruebas. 

• Facilita la integración continua: el TDD es muy adecuado para las prácticas de integración continua, en las que el código en vivo se actualiza continuamente con nuevas características y parches. 

• Depuración reducida: el TDD realiza pruebas de carga frontal en el proceso de desarrollo, lo que reduce la necesidad de una depuración extensa al final del desarrollo. 

• Mayor claridad de los requisitos: el TDD ayuda a los desarrolladores a establecer una comprensión clara de cada requisito específico del programa antes de comenzar a trabajar. 

• Productividad mejorada: el TDD a menudo se vincula con una mayor productividad entre los desarrolladores, ya que el proceso ayuda a atomizar proyectos grandes en pasos más pequeños y más alcanzables. 

• Refuerza el diseño sencillo: el tercer paso crítico del ciclo TDD verde-rojo-refactorizar requiere que los desarrolladores refactoricen y simplifiquen su código. Esta práctica mejora la simplicidad general y la calidad del diseño. 

• Refuerza los modelos mentales: al examinar e integrar cada función o requisito único, el TDD ayuda a los programadores a desarrollar un modelo mental sólido del código en cuestión. Este modelo mental ayuda a los desarrolladores a visualizar las funciones y requisitos generales del código mientras trabajan en él. 

• Mejora de la estabilidad del sistema: se ha demostrado que el uso del desarrollo basado en pruebas mejora la estabilidad general de las aplicaciones mediante la creación de código robusto y bien probado alineado con altos estándares de simplicidad en el diseño.  

Si bien el uso del desarrollo basado en pruebas (TDD) tiene muchos beneficios valiosos, no está exento de desafíos. Si bien la gravedad de estos desafíos puede depender del proyecto o mitigarse con otras técnicas, algunas de las desventajas del TDD incluyen:

• Mayor volumen de código: el TDD requiere que los codificadores no solo escriban código para cada característica requerida, sino también pruebas para cada característica. La adición del código de prueba con el código del producto da como resultado una base de código general más grande. 

• Falsa confianza: como cada característica se escribe para pasar una prueba, los programadores y los gestores de proyectos pueden desarrollar una falsa sensación de seguridad en la funcionalidad general del código. Aunque se prueba cada característica integrada, el TDD no reemplaza la necesidad del control de calidad final y pruebas de API . 

• Mayor sobrecarga: el TDD requiere que los codificadores también mantengan un gran conjunto de pruebas además de su código de producción. El mantenimiento de las bases de código de prueba requiere una cierta cantidad de recursos y puede aumentar los costes generales. 

• Disminución de la eficiencia: aunque se ha demostrado que el TDD mejora la productividad, puede retrasar el desarrollo del proyecto, ya que añade más pasos a la creación e implementación de cada nueva característica. 

• Mayor tiempo de configuración: el TDD requiere que los desarrolladores configuren y mantengan entornos de prueba adecuados para su código. 

• Descuido del diseño general: aunque el TDD fomenta la sencillez del código y mejora el diseño, centrarse demasiado en los componentes individuales puede llevar a un código general menos armonioso. Los programadores que utilizan TDD necesitan saber cómo se integrarán sus actualizaciones de características individuales cuando se compilen en la aplicación de software.