Home Blogs Hay más desarrollo impulsado por pruebas que QA
Applications

Hay más desarrollo impulsado por pruebas que QA

About The Author

Outline

Muchos, si no la mayoría, dentro del mundo del software han llegado a pensar en el desarrollo conducido por pruebas (TDD) de manera estrecha como un proceso único para el desarrollo de software. Muchas discusiones y debates se han centrado en el uso de herramientas o técnicas específicas diseñadas para ejercer cada esquina del código contra una lista predefinida de requisitos con el propósito de demostrar que una base de código determinada funciona como se describe. Como sucede con demasiada frecuencia, se hace difícil separar la señal del ruido y el principio de la práctica, por lo que nos perdemos en los detalles de la implementación y perdemos de vista la intención original. Por lo tanto, vamos a dar un paso atrás y tratar de reconsiderar la conversación en torno al desarrollo impulsado por pruebas: Específicamente, ¿qué es y cómo puede ayudar a su negocio?

¿Qué es TDD?

En el contexto de un negocio, el propósito del software es agregar valor a ese negocio. Debido a esto, uno de los desafíos clave de cualquier esfuerzo de desarrollo es el mapeo de los requisitos y objetivos del negocio en los requisitos del sistema correspondientes. Después de esto, la pregunta se convierte en: ¿Cómo se escribe software para cumplir con estos requisitos, y a medida que su proyecto y su base de código crecen, cómo se asegura de que su software sigue cumpliendo con estos requisitos

Ingrese al desarrollo impulsado por pruebas.

El desarrollo impulsado por pruebas, o TDD, es una metodología organizativa para escribir software mediante la escritura de pruebas que describen y ejercen ese software. En su núcleo, TDD es una repetición de tres pasos: Escribir una prueba fallida, hacer que pase, refactorizar.

La noción es que se comienza con una prueba que describe una pieza de funcionalidad para cualquier característica de software que se está desarrollando. Ejecutar esa prueba por primera vez debería producir un fallo, porque el código que se está probando aún no se ha escrito. Naturalmente, el siguiente paso es ir sobre la implementación de la función, con el objetivo de hacer el pase de prueba original. El tercer paso, y posiblemente el más importante del ciclo de vida, es refactorizar el código.

Escribir software es un desafío no solo por sus cualidades intrínsecas, sino también por su naturaleza dinámica. Los requisitos del negocio pueden cambiar constantemente, y como resultado, los requisitos del software deben ser capaces de adaptarse. El código que está escrito hoy se adaptará a las necesidades de hoy, pero mañana, o un mes a partir de mañana, algo va a cambiar, y como resultado, el código de hoy puede ya no ser la mejor manera de resolver un problema en particular. Mediante la introducción de un mecanismo para comparar lo que el software es haciendo un registro de lo que el software debería ahora tenemos una poderosa herramienta que nos permitirá desgarrar, reescribir y, de lo contrario, volver a cablear nuestro código para cumplir mejor con los requisitos de hoy en día, porque podemos estar seguros de que, mientras pasen todas nuestras pruebas, la salida del sistema debería ser la misma.

¿Por qué deberíamos usar TDD?

Una revisión realizada en 2014 por la Universidad de Helsinki encontró que en muchos casos la TDD produjo efectos positivos en términos de defectos, calidad, complejidad y mantenimiento, pero que estas mejoras pueden venir a costa de mayores esfuerzos de desarrollo. Esta no es una conclusión sorprendente, dado que escribir pruebas adicionales requerirá esfuerzos adicionales, pero lo que los estudios de esta naturaleza parecen dejar de lado es el beneficio clave de TDD, que es la retroalimentación.

Cerrar el bucle de retroalimentación significa acortar la cantidad de tiempo que toma hacer un cambio y aprender algo. Cuanto más rápido puedas hacer esto, más ágil puedes ser. La mayoría de las métricas que tratan de cuantificar la productividad del desarrollo se relacionan con unidades de trabajo a lo largo del tiempo, y al reducir el tiempo que se tarda en recibir retroalimentación accionable, TDD permite un uso más eficiente de ese valioso recurso. Se ha dicho que el tiempo es dinero, por lo que el beneficio económico aquí es evidente. Si alguna vez has escuchado a alguien mencionar un “cambio a la izquierda” en el contexto del ciclo de vida del desarrollo de software, esto es exactamente a lo que se están refiriendo.

Un beneficio adicional de tener un conjunto de pruebas para su aplicación es que puede automatizarlo. Los desarrolladores no solo pueden ejecutar estas pruebas como parte del ciclo de vida del desarrollo, sino que también pueden ser ejecutadas por otros sistemas como parte de la prueba de humo o una tubería de CI/CD. Al automatizar los pasos para entregar código al mercado, permite una entrega más rápida del producto en su conjunto, lo que a su vez acelera la retroalimentación que puede recibir de los usuarios, que luego puede ser interpretada y aplicada a la siguiente iteración.

Los efectos sinérgicos de estos dos puntos son claros: con una base de código que permite a los desarrolladores adaptar continuamente la base de código a las necesidades del negocio, y la capacidad de la empresa para solicitar rápidamente la retroalimentación de sus clientes, el resultado es un sistema que permite a los equipos ofrecer más valor con menos trabajo.

Sacar el máximo provecho de TDD

El desarrollo impulsado por pruebas no es más que uno de los muchos enfoques diferentes para probar software. La parte importante, como quiera que elija implementarlo, es que entrega valor a su organización. Como cualquier otra disciplina, debes sentirte libre de usarlo, adaptarlo como lo consideres conveniente, o no usarlo en absoluto, basado enteramente en las necesidades de tu organización. Dicho esto, si eliges caminar por el camino TDD, como predijo el profeta Clapton: “Es en la forma en que lo usas”.

Al igual que cualquier otro instrumento, la eficacia y el valor de la TDD dependen de su aplicación. Con demasiada frecuencia en el desarrollo de software varias herramientas o técnicas se convierten en chivos expiatorios para explicar los fracasos o deficiencias de un proyecto, pero es un artesano pobre el que culpa a sus herramientas. Así que centrémonos en cómo sacar el máximo provecho de TDD.

Remodelación cultural

El último y más importante paso de TDD es refactorizar el código, pero para que TDD funcione probablemente no sea la única refactorización que debe ocurrir. Si decide implementar alguna forma de desarrollo impulsado por pruebas, es importante que la cultura circundante también se adapte para apoyar este estilo de filosofía de desarrollo.

En el caso de TDD, el fallo más común tiende a ser que el ciclo continuo de pruebas de escritura, haciéndolas pasar, y luego la refactorización nunca se completa realmente, sino que más bien se cortocircuita saltándose el paso de refactorización. La mayoría de las veces el problema no es TDD, o cualquier otra técnica específica, sino más bien la cultura misma en la que se desarrolla el software.

No a diferencia de la documentación, la refactorización parece ser una de las primeras cosas que se arrojan por la borda cuando los plazos o los presupuestos se estrechan porque, después de todo, alguien tiene que escribir todas esas pruebas. Y así se deduce que durante el tiempo de crujido, las pruebas y la documentación, y cualquier otra cosa que no se considere como una misión crítica son desechadas. Lo que se sigue invariablemente es una disminución constante de la calidad general de la base de código y, en su lugar, una acumulación de deuda técnica.

La refactorización es el paso del proceso que se esfuerza por transformar el código que simplemente funciona en una base de código que es más limpia y más mantenible. Es la parte que permite a los desarrolladores dar un paso atrás y reconocer los patrones dentro del sistema en general y tomar decisiones mejor informadas sobre cómo podrían adaptarse para ser más versátiles o para reconocer los anti-patrones emergentes y tomar medidas para mitigarlos. Incluso puede ser la diferencia entre reconocer cuándo es el momento de dividir la arquitectura general en microservicios discretos o cualquier otro de una miríada de mejoras potenciales. Sin este paso, puede perder oportunidades de introspección y mejora incremental, y en última instancia, su base de código corre el riesgo de una transformación gradual (o no) en una gran bola de barro.

Para aprovechar los beneficios del desarrollo impulsado por pruebas, es importante que la cultura tenga una visión larga del proceso en su conjunto, y su potencial, e invierta el tiempo en aplicar el ciclo completo de «rojo, verde, refactor», y no solo los bits que son convenientes.

Shiny New Toys

Cuando se trata del diseño del sistema en su conjunto, a menudo se dedica demasiado tiempo a planificar los detalles de un sistema sin escribir ningún código. Un proyecto de “campo verde” puede ser emocionante, con todo el potencial anticipatorio asociado con una hoja de papel limpia. Ingenieros y arquitectos por igual son víctimas de try-this-itis, donde abogan por el uso de una tecnología de sabor del mes, ignorando cualquiera de las señales de advertencia de que podría no ser una buena opción para este proyecto en particular a favor de la oportunidad de probar algo nuevo o fresco. Avancemos unos meses y el framework-du-jour ya no satisface las necesidades del equipo, la calidad del código está sufriendo, y volvemos a la parte en la que la tecnología se convierte en el chivo expiatorio del mal resultado del proyecto.

Al final del día lo importante es que la tecnología, metodología o marco utilizado para facilitar TDD funciona para el equipo y para el negocio. Si estás atrapado por tus herramientas, no solo no agregan valor, sino que están trabajando activamente en tu contra. Tenga cuidado en evaluar a fondo cualquier marco que tenga la intención de utilizar, y tómese el tiempo para entender exactamente cómo lo usará. Este enfoque es válido para todas las decisiones de diseño, ¡no solo para las relacionadas con TDD!

Envolviendo

En pocas palabras, la idea de algo como TDD es proporcionar un marco para recopilar comentarios de una manera más conveniente y no simplemente una técnica para evitar que aparezcan errores en su base de código. Sea cual sea el enfoque que elija, la clave debe ser que permita a su empresa y su software adaptarse más rápidamente a las tendencias cambiantes y las necesidades del negocio. En el camino, ten en cuenta que TDD y sus contrapartes no son simplemente algo que puedas pedir a tu equipo de desarrollo que implemente y luego olvides, y que para aprovechar eficazmente estas técnicas se debe tener cuidado de adoptar y habilitar el enfoque a nivel cultural antes de sumergirse en detalles de implementación como marcos y herramientas.