¿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 esencialmente obliga a los desarrolladores a ralentizar, validar y refinar su código en ciclos de retroalimentación más cortos. Si bien no es obligatorio, los equipos de DevOps alientan a los programadores, desde principiantes hasta profesionales experimentados, a usar 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 programació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 direccionar inmediatamente 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 refinar su código sobre la marcha, lo que agiliza los controles de calidad y las correcciones finales. 

Los marcos de prueba alternativos incluyen escribir el código de producción antes de escribir todas las pruebas automatizadas o escribir la suite 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.

Si bien el desarrollo basado en pruebas se emplea comúnmente 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 existente desarrollado con técnicas más antiguas u otras. 

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 legibilidad del código al promover flujos de trabajo comprobables que dan como resultado un código de alta calidad a nivel unitario. 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 la TDD de aceptación, a veces llamada Desarrollo basado en el comportamiento (BDD), los programadores escriben una única prueba de aceptación y luego suficiente código nuevo para pasar. Las pruebas de aceptación a veces se denominan pruebas del 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 los stakeholders. ATDD se esfuerza por identificar requisitos detallados y ejecutables. Las pruebas de aceptación se pueden realizar empleando 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. 

Al emplear una estrategia de desarrollo basada en pruebas, los programadores primero escriben pruebas para verificar cada elemento o función individual de una pieza de software antes de escribir suficiente código para pasar esa prueba individual. Una vez completado, el software se prueba nuevamente y, si pasa, el código se refina (un proceso conocido como refactorización) para incluir solo los elementos esenciales. Luego, 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 de una determinada función de software, los desarrolladores escriben primero una prueba unitaria individual para esa función.
2. Luego, los desarrolladores 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 arroja 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 sólo 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 fallida para el comportamiento previsto del software. 

• Verde: escriba suficiente información adicional para aprobar el examen.

• 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 los stakeholders 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". Si bien Myers podría no haber sido el creador de este concepto, su trabajo dio crédito a una noción común que se extendería en 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 basado en pruebas e introduciendo el concepto crítico de objetos simulados. 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 que se pueden verificar para funcionar 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, popularizando la práctica entre la comunidad de desarrollo en general y legitimando aún más las pruebas impulsadas por 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 insight 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 otros stakeholders 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 obtienen una mayor confianza no solo en su código sino también en sus pruebas. 

• Facilita la integración continua: el TDD es adecuado para 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 carga las pruebas en el proceso de desarrollo, lo que reduce la necesidad de una depuración extensa al final del desarrollo. 

• Mejora de la 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 mitigar con varias 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. Agregar el código de prueba con el código del producto da como resultado una base de código general más grande. 

• Falsa confianza: a medida que cada característica se escribe para pasar una prueba, los programadores y gerentes de proyecto 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 de control de calidad final y pruebas de API . 

• Mayor sobrecarga: el TDD requiere que los programadores mantengan un amplio suite de pruebas además de su código de producción. El mantenimiento de bases de código de prueba requiere una cierta cantidad de recursos y puede aumentar los costos generales. 

• Disminución de la eficiencia: Si bien se demostró que el TDD mejora la productividad, puede retrasar el desarrollo del proyecto, ya que agrega 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.