4 consejos para adoptar el desarrollo basado en pruebas (TDD) en su organización

¿Cómo implementa con éxito TDD en su organización?

Aprenda a maximizar los beneficios de adoptar TDD y explore el espectro de adopción de TDD, desde purista hasta TDD-ish.

El desarrollo impulsado por pruebas (TDD) se trata de escribir código delgado y medio con un alto nivel de cobertura de pruebas. Los desarrolladores escriben la prueba para un requisito antes de escribir el código, y el código se considera terminado tan pronto como pasa la prueba. Suena genial, pero ¿cómo implementa con éxito TDD en su organización? Exploraremos esto aquí y le daré algunos consejos para maximizar los beneficios de adoptar TDD.

¿Por qué TDD?

El principal beneficio de TDD es que ayuda a los desarrolladores a crear código comprobable y mantenible. TDD también previene el deslizamiento de características y el "chapado en oro" del código al garantizar que se crea el código mínimo necesario para implementar la funcionalidad. Validar que se está escribiendo el código correcto también hace que los equipos sean más eficientes y evita desperdiciar valiosos recursos de desarrollo en la construcción de la funcionalidad incorrecta.

Seguir TDD impone las pruebas unitarias como una práctica dentro de la organización. Pero esto no es una prueba unitaria por el bien de la prueba unitaria. Es una forma de asegurarse de que está creando un código comprobable, lo que lo ayuda a reducir los costos de mantenimiento y mantener baja la deuda técnica. Al asegurarse de tener un conjunto de regresión sólido, se le notifica instantáneamente cuando algo se rompe como resultado de cambios en el código.

Una gran razón para el creciente interés en TDD es que muchas organizaciones están haciendo la transición a prácticas de desarrollo ágiles y se están dando cuenta de que sus prácticas de prueba existentes dependen demasiado de las pruebas manuales de fin de ciclo. Ciertamente, existe un lugar para las prácticas de prueba de extremo a extremo, pero para escalar la innovación de desarrollo a la velocidad necesaria para seguir siendo competitivas, las organizaciones deben cambiar los esfuerzos de prueba que quedan. TDD es un proceso que prácticamente garantiza que inicie proyectos de desarrollo con una base sólida de pruebas para garantizar la calidad del software durante todo el ciclo de vida del desarrollo.

El espectro TDD

A efectos prácticos, muy pocas personas que desarrollan software siguen la visión pura de TDD, por varias razones. El desarrollo de software moderno generalmente implica la integración de bibliotecas, la conexión de código heredado y la ampliación de la funcionalidad existente. Muchas personas no pueden darse el lujo de escribir un código completamente nuevo, por lo que TDD puro no es práctico en muchos casos. En cambio, muchas personas "haciendo TDD" se sientan en algún lugar de un espectro que se parece a esto:

Si bien cada organización tiene su propio conjunto de desafíos específicos con TDD, los problemas que más escuchamos de nuestros clientes encajan en los tres tipos básicos anteriores. Pero dentro de ese espectro, hay muchos tipos de practicantes de TDD:

Ninjas TDD

En un extremo del espectro están las personas que están practicando con éxito TDD en el nivel de "cinturón negro". Estas personas están totalmente comprometidas con los principios de TDD y no escriben cualquier cosa antes de escribir las pruebas (sin esqueleto, sin definiciones, sin nada) y se terminan tan pronto como pasa la prueba. Como resultado, el código es altamente eficiente y de fácil mantenimiento. Cuando hablamos con ninjas TDD, a menudo reconocen que su éxito en la implementación de TDD es desigual en los equipos de su organización.

Pragmatistas TDD

Los siguientes en el espectro son las personas que pueden diseñar clases, firmas de métodos, etc., y luego escribir pruebas contra esas definiciones. A nivel de API, esto equivale a escribir la definición de OpenAPI / Swagger o WSDL. A esto lo llamamos el enfoque pragmático de TDD.

Este enfoque es un poco más fácil de adoptar porque proporciona más estructura y mayor claridad. Todo se compila para que un escuadrón pueda trabajar en conjunto más fácilmente. Sin embargo, la compensación potencial es que los pragmáticos de TDD no siempre logran el diseño de código mínimo y altamente eficiente que logran los ninjas de TDD.

TDD para Legacy

Hay muchas personas a las que les encantaría comprometerse completamente con TDD, pero no pueden darse el lujo de comenzar con un código nuevo. Estas personas a menudo crean pruebas para reproducir un defecto o para probar el comportamiento esperado, con el fin de cambiar o ampliar la funcionalidad existente según el código heredado.

En nuestra experiencia, un gran segmento de aquellos que se identifican a sí mismos como practicantes de TDD se encuentran en este punto del espectro o cerca de él. La lógica es que aunque la prueba y el código están inextricablemente vinculados, la prueba no necesariamente mencionadas el código. Las pruebas, sin embargo, preceden al cambios al código.

TDD-ish

En el otro extremo de nuestro espectro de aquellos que se identifican a sí mismos como TDD están las personas que prueban y codifican en paralelo. Para los profesionales de TDD, siempre que la prueba y el código se comprometan y gestionen juntos, se considera que el desarrollo está impulsado por pruebas.

4 consejos para implementar el desarrollo basado en pruebas (TDD)

Entonces, ¿cómo adoptas TDD con éxito? Siga los cuatro consejos a continuación para lograr el éxito de TDD.

1. Aplicar TDD al código heredado

Un problema común de implementación de TDD asoma su fea cabeza cuando una organización ha heredado un código no comprobable y no tiene la capacidad de pagar la deuda técnica. ¿Debería refactorizarse el código? Si es así, ¿cuánta refactorización es necesaria para comenzar a practicar TDD de una manera significativa y alcanzable?

Si hay un mandato para comenzar a hacer TDD en código heredado, intentar implementar TDD ideal no funcionará. El código que está heredando no se creó teniendo en cuenta la capacidad de prueba, es posible que el autor original ya no esté en el equipo o incluso en la organización, las bibliotecas dependientes pueden haber cambiado, etc.

Por lo tanto, si el código heredado ya está disponible y funcionando, el riesgo asociado con la deuda técnica es bajo en relación con el riesgo de un nuevo trabajo no probado. Al aplicar TDD al nuevo código que está escribiendo, es decir, cambios en el código existente, minimiza el riesgo y no aumenta la deuda técnica.

Para superar los desafíos de probar el código existente, puede utilizar Prueba J de ParasoftLa capacidad de prueba unitaria de para crear rápidamente pruebas significativas. Parasoft Jtest analiza el código heredado y sus dependencias, lo que reduce la cantidad de tiempo necesario para crear casos de prueba JUnit e implementar el complejo stubing/mocking necesario para el código preexistente.

2. Aplicar TDD a Microservicios

Las arquitecturas basadas en microservicios tienen muchas más dependencias y complejidad que las pilas de aplicaciones tradicionales, lo que introduce una volatilidad significativamente mayor en el entorno de prueba. La creación de pruebas para aplicaciones basadas en microservicios y otras arquitecturas complejas puede resultar difícil debido al requisito de simulacros y apéndices avanzados.

Sin embargo, una arquitectura basada en microservicios presenta la oportunidad de aprovechar las mejores prácticas de TDD de una manera muy eficiente. Si piensa en tratar el microservicio como la unidad, en lugar de la unidad de compilación, entonces el enfoque pragmático TDD se vuelve muy útil.

Al aplicar TDD a nivel de API, su API se define en el contrato (OpenAPI/Swagger, WSDL). Un Solución de prueba API, Tales como Prueba SOA de Parasoft, puede crear automáticamente pruebas basadas en esas definiciones. Está listo para desarrollar la funcionalidad de acuerdo con las definiciones hasta que pasen las pruebas de SOAtest.

3. Habilitar el escuadrón

TDD se ve comúnmente como una actividad centrada en el desarrollador, típicamente encapsulada mediante la creación de pruebas en un marco de prueba unitaria, como JUnit o NUnit. Sin embargo, la mayoría de las organizaciones simplemente no tienen suficientes desarrolladores o tiempo para cubrir todos sus casos de uso. Esto es especialmente un problema para las organizaciones empresariales que tienen una combinación de roles y habilidades que contribuyen a sus proyectos.

Aprovechar las prácticas de TDD a nivel de API, como se describe anteriormente para los microservicios, lo ayuda a abordar el problema de los recursos técnicos limitados al permitirle aprovechar la experiencia de los probadores para definir las pruebas contra el contrato. Con este enfoque, los analistas comerciales, evaluadores y otros recursos que no son desarrolladores pueden contribuir a los esfuerzos de prueba de TDD.

También puede utilizar una solución de virtualización de servicios, como Virtualización de Parasoft, para crear inmediatamente una funcionalidad simulada con la que puede crear y ejecutar pruebas antes de escribir cualquier código.

4. Mejore TDD con BDD

Como hemos comentado, existen varios beneficios de implementar TDD, pero TDD por sí solo no se traduce necesariamente en un código que cumpla con los requisitos. Solo asegura que el código esté cubierto por pruebas y que las pruebas pasen. Aquí es donde Comportamientoentra en juego el desarrollo impulsado por el sistema (BDD). En lugar de escribir código hasta que pase la prueba, los desarrolladores escriben código hasta que se implementa el comportamiento.

Vale la pena señalar que ha habido intentos en el pasado de definir el marco funcional antes de escribir el código. (¿Alguien recuerda el diseño por contrato (DbC)?) De hecho, BDD es el intento más reciente de implementar tal enfoque. En BDD (o DbC, para el caso), las condiciones previas y posteriores deben definirse antes de crear una prueba o código.

BDD representa una oportunidad para llevar TDD al siguiente nivel. Si usa un lenguaje BDD, como Gherkin, puede escalar las pruebas de automatización. Y Parasoft SOAtest (para pruebas de API) y Parasoft Selenic (para Pruebas de IU impulsadas por selenio) puede reducir la complejidad técnica de escribir el código de unión necesario y las definiciones de pasos que normalmente requieren recursos de desarrollador.

Conclusión

La promesa del desarrollo basado en pruebas se basa en un espíritu de desarrollo esbelto. Busca ayudarlo a producir código eficiente, comprobable y mantenible. Pero las condiciones del mundo real no siempre facilitan la adopción de TDD. Parasoft lo ayuda a adoptar prácticas de TDD de una manera práctica para su organización, lo que le permite maximizar sus recursos de desarrollo/prueba.