TDD/BDD Práctico para aplicaciones con dominio rico
Barcelona Software Crafmanship 2014
@eferro
@nestorsalceda
Alea Soluciones
ContextoTipo de aplicaciones
Delivery mechanisms
Sistemas de gestión de información
Sistemas de monitorización/control/scada
Sistemas de orquestación y configuración
Para desarrolloBounded contexts
DDD / OOP
Sin acoplamiento al framework
TDD a cascoporro
Pirámide de testing
TDD Mockist
Entrando por lógica de dominio
Test unitarios con aislamiento por clase
ConclusionesBuena 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
TDD por funcionalidad
Test unitario con aislamiento por funcionalidad
Outside In. Comenzando por lógica de negocio
Negocio puro y duro
ConclusionesTerminologia 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
Dificultades
Necesitas arquitectura hexagonal o similar
Cuesta identificar los puertos
Requiere algo más de poder mental. Se pueden usar mocks como andamiaje
¿Cómo lo hacemos actualmente?
Flujo por funcionalidad
Green Field
Análisis
Identificar puertos
Dobles para puertos
Adaptadores (Repositorios, Servicios, SNMP …)– Tests de contrato
– TDD con dobles para los wrappers de librerías
Flujo por funcionalidad
Brown Field
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
¡Enséñame los tests!
Números
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
¡Gracias!
Top Related