Diseño guiado por Mocks y Test Unitarios

juancarlos.vergara@agile‐works.com

AgendaAgenda

• Introducción• Introducción• Caso de Estudio• Caso de Estudio• ConclusionesConclusiones

IntroducciónIntroducción

Un nuevo proyecto deUn nuevo proyecto de software requiere cosas que 

h li dno se hayan realizado antes:GenteDominio de la soluciónT l íTecnologíaCombinación anteriores

Los desarrolladores noLos desarrolladores no entendemos completamente la t l ítecnología a usar, necesitamos aprender ennecesitamos aprender en el camino.

Todos sabemos que van haberTodos sabemos que van haber cambios pero no sabemos que tipo de cambiostipo de cambios.

N iNecesitamos un proceso que ayude enfrentar la yincertidumbre. 

Para reducir riesgos necesitamos usar gciclos de actividades.

En cada ciclo se agregan nuevas características y se obtienecaracterísticas y se obtiene retroalimentación empírica acerca de la calidad y cantidad del trabajola calidad y cantidad del trabajo realizado.

El equipo divide el trabajo enEl equipo divide el trabajo en periodos de tiempo fijos, dentro de los cuales se analizadentro de los cuales se analiza, diseña, implementa y , p ydespliega funcionalidad completacompleta.

Para aplicar ciclos dePara aplicar ciclos de retroalimentación, se organizan los proyectos 

i t dcomo un sistema de ciclos anidadosciclos anidados.

La duración de cada ciclo puede variar desde segundos a meses:

Pair ProgrammingPair ProgrammingTest UnitariosPruebas de AceptaciónPruebas de AceptaciónReuniones DiariasIteraciones

lReleases

Cada ciclo expone los artefactosCada ciclo expone los artefactos producidos por el equipo a retroalimentación empíricaretroalimentación empírica.

D l dDe tal manera que se pueda descubrir y corregir errores o y gmala interpretaciones.

Cada ciclo controlaCada ciclo  controla diferentes aspectos deldiferentes aspectos del sistema y del proceso y pde desarrollo.

Los ciclos más internosLos ciclos más internos están enfocados en elestán enfocados en el detalle técnico.

Los ciclos más externosLos ciclos más externos están enfocados en la organización y el equipo.

Para cualquier sistema no trivial, las pruebas manuales son imprácticas.

Son demasiado lentas para tener ciclos deSon demasiado lentas para tener ciclos de retroalimentación óptimos.

Automatizar para reducir costo y tiempo en construir, desplegar y modificar versiones del isistema.

Para hacer eficientes los ciclosPara hacer eficientes los ciclos necesitamos mantener el código lo más simple posible que sealo más simple posible, que sea fácil de entender y modificar.

SimplicidadSimplicidad requiere esfuerzo:requiere esfuerzo: RefactoringRefactoring

Las pruebas automáticasLas pruebas automáticas, nos protegen contra 

didnuestros errores a medida que mejoramos nuestroque mejoramos nuestro código

Pocos desarrolladores “disfrutan” de probar su propio código.

Crear pruebas automatizadas no es percibido como un trabajo real sinopercibido como un trabajo real sino aburrido comparado con desarrollar nueva funcionalidadnueva funcionalidad.

TDD t t dTDD trata de cambiar esta situaciónsituación.

TDD cambia el proceso deTDD cambia el proceso de pruebas, de una actividad pde verificación hacia una ti id d d di ñactividad de diseño.

Escribir las pruebas antesEscribir las pruebas antes que el código, ayuda a  q g yaclarar nuestras ideas b l tisobre lo que tiene que 

hacer el códigohacer el código.

Las pruebas nos proveenLas pruebas nos proveen de una red de seguridad gbasadas en pruebas de 

ióregresión.Nos dan confianza paraNos dan confianza para realizar cambios.

Como saber cuandoComo saber cuando empezar y terminarempezar y terminar de escribir códigode escribir código.

Caso de EstudioCaso de Estudio.P dProceso de 

i ió dReposición de Productos

• Cadena farmacéutica• Locales piden reposición productos a matriz según demanda.

• Comunicación entre matriz y locales mediante gateways implementados con webservices

• Para asegurar la escalabilidad de la aplicación el payload es almacenado en una cola JMS.

• COMMAND: Reposicion,COMMAND: Reposicion, CodLocal=0052,CodProducto1=100007777559100007777559, CodProducto2=100007777560, CodProducto 00007777560,CodProducto3=100007777561,TiP did NORMALTiPedido=NORMAL.

Cuando un pedido especial es atendido, la solicitud se muestra en un visor donde un encargado de logística aprueba o deniega el pedido respectivo.

La información de cada producto es obtenida desde el catalogo de productos que es un servicio con interfaces RESTFul que proporciona información de cada productoproporciona información de cada producto como descripción, precio unitario, etc.

La cantidad a reponer es determinada por el servicio de reposición de productos.p p

Una vez atendido el pedido de reposición se l í d i ió lgenera la guía de remisión para los 

productos solicitados.

Ubiquitous LanguageSolicitud de Reposición: Conjunto de 

Ubiquitous Language

productos solicitados por un local para aumentar su stock físico.

Producto: Ítem que puede ser catalogado (precio y descripción) y repuesto.(precio y descripción) y repuesto.

Reponer: Aplicación del algoritmo de i ió d i l id d d lreposición para determinar la cantidad del 

producto que se debe enviar al local que lo solicitósolicitó.

Descomposición Funcional1. Pedido Normal, 1 Producto, Catalogar2 Pedid N l 1 P d t Re e2. Pedido Normal, 1 Producto, Reponer3. Pedido Normal, Generar Guía de Remisión4 P did E i l 1 P d t A b4. Pedido Especial, 1 Producto, Aprobar5. Pedido Especial, 1 Producto, aprobar,

catalogar reponercatalogar, reponer 6. Pedido Normal, varios Productos7 Pedido Especial varios productos aprobar7. Pedido Especial, varios productos, aprobar,

generación guía remisión

Infraestructura de Soporte

Ayuda a entender los requerimientos y

Infraestructura de Soporte

Ayuda a entender los requerimientos y a proponer y validar un esbozo de la arquitectura, se puede cambiar de punto de vista posteriormente peropunto de vista posteriormente pero es necesario empezar con algo que de cierta perspectiva

Test para guiar la creación i f t t d S tinfraestructura de Soporte

CódigoCódigo

Mock ObjectsMock Objects

Un sistema orientado a objetosUn sistema orientado a objetos esta organizado como una red de esta organi ado como una red deobjetos colaboradores

Mock ObjectsMock Objects

Para probar un objeto probamosPara probar un objeto, probamos las interacciones con los objetos las interacciones con los objetosvecinos.

Verificar ExpectativasVerificar ExpectativasHamcrest es un framework para declarar criterios de pcorrespondencia.

Un Matcher reporta si un objeto cumple con un d t i d it ideterminado criterio.

String s = "El color del carro es rojo";String s =  El color del carro es rojo ;Matcher<String> esRojo = new StringContains("rojo");Matcher<String> esAzul = new StringContains("azul");Matcher<String> esAzul  new StringContains( azul );assertTrue(esRojo.matches(s));assertFalse(esAzul.matches(s));( ( ));

CódigoCódigo

Métodos CompuestosMétodos Compuestos

Divida su programa en métodos que realicenDivida su programa en métodos que realicen una única tarea identificable.

Mantenga todas las operaciones del método al mismo nivel de abstracción.

Esto conduce naturalmente a programas con muchos métodos cada uno de pocas líneas demuchos métodos cada uno de pocas líneas de tamaño.

CódigoCódigo

Principio de Responsabilidad Ú iÚnica

Cada objeto debe tener una solaCada objeto debe tener una sola responsabilidad, definida sin ambigüedades.

Cuando agregamos comportamiento a un sistema, este principio ayuda a extender un objeto existente o crear un nuevo servicio a ser invocado desde el objeto. j

CódigoCódigo

MavenMaven

Ejecución PruebasEjecución Pruebas.

Integración Motores de Integración Continua

Entorno headless en linux para no interrumpir el escritorio.p

Cobertura para Code Coverage.

C lid d d CódiCalidad de Código.

ConclusionesConclusiones

El dominio esta estructurado en base a interfaces queEl dominio esta estructurado en base a interfaces que hacen el sistema ensamblable, pues se puede alterar el comportamiento del sistema cambiando la definición de sus objetos.

Ninguno de los objetos expone su estructura interna ni t d t h l á fá il destado,  esto hace los programas más fáciles de 

mantener y modificar.

Es recomendable empezar con una prueba fallida y queEs recomendable empezar con una prueba fallida y que ésta dirija  la implementación de la funcionalidad requerida desde algún objeto de interface.q g j