Tdd bdd-practico-dominio-rico
0 recomendaciones717 vistas
El documento discute prácticas de TDD y BDD aplicadas a aplicaciones de dominio rico, enfocándose en la importancia de la cobertura de pruebas y la granulosidad en el manejo de errores. Se presentan conclusiones sobre el costo de mantenimiento y refactorización, así como la necesidad de arquitecturas hexagonales para facilitar el desarrollo. Además, se destacan estadísticas sobre la eficiencia y rapidez en la ejecución de pruebas unitarias e integración.
Tdd bdd-practico-dominio-rico
- 1. TDD/BDD Práctico para aplicaciones con dominio rico Barcelona Software Crafmanship 2014
- 2. @eferro
- 5. Contexto Tipo de aplicaciones Delivery mechanisms Sistemas de gestión de información Sistemas de monitorización/control/scada Sistemas de orquestación y configuración
- 6. Para desarrollo Bounded contexts DDD / OOP Sin acoplamiento al framework TDD a cascoporro
- 9. TDD Mockist
- 10. Entrando por lógica de dominio Test unitarios con aislamiento por clase
- 11. Conclusiones Buena cobertura Granularidad en caso de error muy buena. A veces rompen en cascada. Poco coste mental una vez aprendido el proceso Coste alto de mantenimiento / refactor
- 13. Test unitario con aislamiento por funcionalidad Outside In. Comenzando por lógica de negocio Negocio puro y duro
- 14. Conclusiones Terminologia de negocio Buena cobertura Granularidad en caso de error muy buena Coste bajo de mantenimiento Se disfruta refactorizando Menor tendencia a megaconstrucciones Valor de negocio más rápido Feedback mucho antes
- 15. Dificultades Necesitas arquitectura hexagonal o similar Cuesta identificar los puertos Requiere algo más de poder mental. Se pueden usar mocks como andamiaje
- 16. ¿Cómo lo hacemos actualmente?
- 17. Flujo por funcionalidad Green Field
- 18. Análisis Identificar puertos Dobles para puertos Adaptadores (Repositorios, Servicios, SNMP …) – Tests de contrato – TDD con dobles para los wrappers de librerías
- 19. Flujo por funcionalidad Brown Field
- 20. Análisis / ¿Dónde impacta? “For each desired change, make the change easy (warning: this may be hard), then make the easy change” Kent Beck Dobles como puertos Adaptadores (Repositorios, Servicios, SNMP …) – Tests de contrato – TDD con dobles para los wrappers de librerías
- 23. Números
- 24. 660 test unitarios de clase / 1 segundo 180 test unitarios de funcionalidad / 0.6 segundos 180 tests de integración / 14 segundos – Unos 50 de contrato
- 25. ¡Gracias!