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!