TDD no le dirá qué componentes construir. Pero puede usar los principios TDD para perfeccionar su arquitectura. Sin embargo, el uso de los principios TDD es más beneficioso si no considera que la “arquitectura” está limitada al diseño del software.
La cuestión es que cada vez que construyes algo, comienzas a hacer suposiciones. Estás confiando en tu instinto para hacer esas suposiciones. En un modelo de desarrollo de Waterfall, pasaste tiempo durante la fase de análisis haciendo POCs para examinar esas suposiciones.
Sin embargo, cuando se encuentra en un mundo ágil, no desea realizar costosos esfuerzos de POC por adelantado, porque es probable que las suposiciones que haya investigado puedan cambiar. En cambio, debe pensar en examinar sus suposiciones en un ecosistema que emplea Entrega Continua. Realiza una suposición, construye el sistema a partir de la suposición, la lanza a producción y luego ve si tu suposición es válida en el mundo real. Si no lo hace, revierte, o vuelves a diseñar. Agile se basa en su capacidad para realizar pequeños cambios de forma iterativa y rápida. Esto le permite diseñar su sistema como una iteración de experimentos: – hipotetizar, implementar, observar. Claro, no puedes construir todo de esta manera, y debes tomar algunas decisiones importantes por adelantado. Sin embargo, puede posponer las pequeñas suposiciones hasta que necesite
- En ingeniería de software, ¿cuál es la diferencia entre alto acoplamiento y baja cohesión?
- ¿Cuáles son los conceptos principales que todo programador de C ++ debe saber sobre el lenguaje?
- Al contratar a un desarrollador junior, ¿qué tiene prioridad: cartera, conocimiento de un sistema o versatilidad?
- ¿Cuáles son las aplicaciones de la serialización de objetos en ingeniería de software?
- ¿Cómo puede un chico de 32 años de habla inglesa (que dejó su doctorado y no es ciudadano de la UE) encontrar un trabajo en software en la UE?
Entonces, ¿cómo ayuda TDD? Bueno, si va a hacer suposiciones arquitectónicas y lanzar código experimental a la producción basado en suposiciones, es mejor que se asegure de que sus experimentos no afecten la propuesta comercial de su producto … o si lo hacen, debe saber immeditelt Entonces, por ejemplo, supongamos que tiene 2 enfoques para un algoritmo que hace que su sitio venda más Widgets, y no puede decidir entre los 2, usted construye 1 y lo lanza a producción. Una vez lanzado, debe poder medir qué tan bien está funcionando ese algoritmo y recopilar métricas.
Esto es esencialmente TDD a nivel arquitectónico. Cada vez que hace una suposición, diseña una prueba que prueba la suposición. Implementa esa prueba junto con la implementación de la función. Una vez que la función se lanza a producción, ejecuta las pruebas que le indican si sus suposiciones se mantienen.
Existen otras técnicas de entrega continua que pueden ayudarlo en esto. Por ejemplo, puede usar pruebas A / B. Puede lanzar una función implementada en base a una suposición a A, y luego ejecutar sus pruebas en A antes de lanzarla al público en general. Si está utilizando bliki: BlueGreenDeployment, puede ejecutar sus pruebas mientras mueve los usuarios de Azul a Verde. Si las pruebas fallan, puede comenzar a moverlas nuevamente a Azul.