Enfoque de desarrollo de prueba para el desarrollo de software ágil

Ahora, la gente a menudo habla de desarrollo ágil.

¿Qué es el desarrollo ágil?

El desarrollo ágil  es una capacidad de desarrollo de software que responde a necesidades que cambian rápidamente. Sus nombres específicos, conceptos, procesos y terminología varían. En comparación con » no ágiles «, enfatizan la estrecha colaboración entre los equipos de programadores y los expertos comerciales, la comunicación cara a cara (considerada más efectiva que la documentación escrita) y, con frecuencia, entregan nuevas versiones de software,  equipos pequeños y autoorganizados  para pequeños y enfoques de escritura de características valiosas y organización de equipos que se adaptan a las necesidades cambiantes, con un mayor enfoque en el papel de las personas en el desarrollo de software.

Sin embargo, existen varias versiones similares de métodos de desarrollo ágil de TDD, como TDD: BDD, DDD y ATDD. Permítanme presentarles brevemente estos métodos antes de presentar TDD en detalle:

TDD: desarrollo basado en pruebas

Test Driven Development  (TDD) es un proceso de desarrollo de software, que se basa en transformar los requisitos de software en casos de prueba antes de que el software esté completamente desarrollado, y rastrear todo el desarrollo de software probando repetidamente el software para todos los casos de prueba. Esto es lo opuesto a desarrollar software primero y luego crear casos de prueba. Algunos modelos populares admiten muy bien TDD, como MVC y  MVP .

BDD: Desarrollo impulsado por el comportamiento (Behavior Driven Development)

El desarrollo impulsado por el comportamiento (BDD) también es un proceso ágil de desarrollo de software. Fomenta la colaboración entre desarrolladores, evaluadores de control de calidad y representantes de clientes en proyectos de software. Alienta a los equipos a usar conversaciones y ejemplos concretos para formalizar un entendimiento común de cómo debería funcionar la aplicación. Proviene del desarrollo guiado por pruebas (TDD).

ATDD: Desarrollo impulsado por pruebas de aceptación

Para promover la realización de código funcional a través de casos de prueba de unidad, el equipo debe definir los estándares de calidad esperados y las reglas de aceptación, y promover la práctica de TDD de los desarrolladores y el desempeño de los probadores a través de un plan de prueba de aceptación claro y consistente (que incluye una serie de pruebas). escenarios). Para los desarrolladores, enfatiza cómo implementar el sistema y cómo probarlo.

DDD: diseño de unidades de dominio

DDD se refiere al diseño impulsado por el dominio, es decir, el desarrollo impulsado por el dominio. En realidad, DDD se basa en esta base porque se enfoca en el diseño de la capa de servicio, se enfoca en la implementación comercial, combina análisis y diseño, y ya no lo mantiene en un estado dividido, para implementar de manera correcta y completa las necesidades del cliente y construir un modelo de negocio. escalabilidad

Plan de implementación de TDD

A través de las pruebas para promover todo el desarrollo, pero el desarrollo basado en pruebas no es solo un simple trabajo de prueba, sino un proceso de cuantificación de análisis de requisitos, diseño y control de calidad.

Principios de desarrollo

Escriba primero el código de prueba y luego escriba el código para la función.

1. Escriba el código de prueba de acuerdo con el documento de requisitos, para no realizar la función;
2. No quiero engordar de un bocado. Al probar bloques funcionales grandes, primero debe dividirlos en bloques funcionales más pequeños para realizar pruebas;
3. Recuerde no escribir código para completar la función, use el código más simple posible para implementar la función;
4. Si los requisitos se pueden probar, escriba código de prueba y renuncie a aquellos que no se pueden probar o sienta que no necesitan probarse;
5. Antes de cambiar/agregar cualquier código de función, primero debe pensar si desea cambiar/agregar casos de prueba;
6. Función/código de prueba, estructura irrazonable, código duplicado, etc., refactorizar en el tiempo después de que pase la prueba.

Proceso de desarrollo de TDD

1. Analizar y determinar un escenario de prueba objetivo;
2. Agregue una prueba unitaria para verificar la entrada y salida del escenario de prueba;
3. Ejecute la prueba y obtenga el resultado de la prueba fallida;
4. Escriba el código de función más simple para pasar la prueba;
5. Vuelva a ejecutar la prueba y compruebe que pasa;
6. Llevar a cabo la refactorización del código, incluido el código funcional y el código de prueba de la unidad;
7. Repita los pasos anteriores hasta completar el desarrollo.

Beneficios de TDD

1. Reducir la carga de los desarrolladores . A través de un proceso claro, centrémonos en un solo punto a la vez, y la carga de pensar es menor.
2. La red de protección . Cubrir las pruebas unitarias completas proporciona una red protectora para el código del producto, lo que facilita el cumplimiento de los cambios en los requisitos o la mejora del diseño del código. Entonces, si los requisitos de su proyecto son estables, se realizan de una vez y no hay cambios posteriores, los beneficios de TDD son menores.
3. Aclare los requisitos con antelación . Escribir pruebas primero puede ayudarnos a pensar en los requisitos y aclarar los detalles de los requisitos con anticipación, en lugar de descubrir requisitos poco claros solo a la mitad del código.
4. Comentarios rápidos . Mucha gente dice que cuando TDD, mi volumen de código aumenta, por lo que la eficiencia de desarrollo disminuye. Sin embargo, si no tiene pruebas unitarias, debe probarlas manualmente, dedica mucho tiempo a preparar datos, iniciar aplicaciones, modificar interfaces, etc., y la retroalimentación es lenta. Para ser precisos, la retroalimentación rápida es un beneficio de las pruebas unitarias.