• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Aw Tdd Mocks Design 1.2
 

Aw Tdd Mocks Design 1.2

on

  • 952 views

 

Statistics

Views

Total Views
952
Views on SlideShare
950
Embed Views
2

Actions

Likes
0
Downloads
10
Comments
0

1 Embed 2

http://javaycafe.blogspot.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Aw Tdd Mocks Design 1.2 Aw Tdd Mocks Design 1.2 Presentation Transcript

    • Diseño guiado por Mocks y Test Unitarios juancarlos.vergara@agile‐works.com
    • Agenda • Introducción • Caso de Estudio Caso de Estudio • Conclusiones
    • Introducción Un nuevo proyecto de  Un nuevo proyecto de software requiere cosas que  no se hayan realizado antes: h li d Gente Dominio de la solución Tecnología T l í Combinación anteriores
    • Los desarrolladores no  Los desarrolladores no entendemos  completamente la  tecnología a usar,  t l í necesitamos aprender en  necesitamos aprender en el camino.
    • Todos sabemos que van haber  Todos sabemos que van haber cambios pero no sabemos que  tipo de cambios. tipo de cambios Necesitamos un proceso que  N i ayude enfrentar la  y incertidumbre. 
    • Para reducir riesgos necesitamos usar  g ciclos de actividades. En cada ciclo se agregan nuevas  características y se obtiene  características y se obtiene retroalimentación empírica acerca de  la calidad y cantidad del trabajo  la calidad y cantidad del trabajo realizado.
    • El equipo divide el trabajo en  El equipo divide el trabajo en periodos de tiempo fijos,  dentro de los cuales se analiza,  dentro de los cuales se analiza , p diseña, implementa y  y despliega funcionalidad  completa. completa
    • Para aplicar ciclos de  Para aplicar ciclos de retroalimentación, se  organizan los proyectos  como un sistema de  it d ciclos anidados. ciclos anidados
    • La duración de cada ciclo puede variar desde  segundos a meses: Pair Programming Test Unitarios Pruebas de Aceptación Pruebas de Aceptación Reuniones Diarias Iteraciones Releases l
    • Cada ciclo expone los artefactos  Cada ciclo expone los artefactos producidos por el equipo a  retroalimentación empírica. retroalimentación empírica De tal manera que se pueda  D l d descubrir y corregir errores o  y g mala interpretaciones.
    • Cada ciclo  controla  Cada ciclo controla diferentes aspectos del  diferentes aspectos del sistema y del proceso  y p de desarrollo.
    • Los ciclos más internos  Los ciclos más internos están enfocados en el  están enfocados en el detalle técnico.
    • Los ciclos más externos  Los 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 de  Son demasiado lentas para tener ciclos de retroalimentación óptimos. Automatizar para reducir costo y tiempo en  construir, desplegar y modificar versiones del  sistema. i
    • Para hacer eficientes los ciclos  Para hacer eficientes los ciclos necesitamos mantener el código  lo más simple posible, que sea  lo más simple posible que sea fácil de entender y modificar.
    • Simplicidad  Simplicidad requiere esfuerzo:  requiere esfuerzo: Refactoring
    • Las pruebas automáticas,  Las pruebas automáticas nos protegen contra  nuestros errores a medida  did que mejoramos nuestro  que mejoramos nuestro código
    • Pocos desarrolladores “disfrutan” de  probar su propio código. Crear pruebas automatizadas no es  percibido como un trabajo real sino  percibido como un trabajo real sino aburrido comparado con desarrollar  nueva funcionalidad. nueva funcionalidad
    • TDD trata de  TDD t t d cambiar esta  situación. situación
    • TDD cambia el proceso de  TDD cambia el proceso de p pruebas, de una actividad  de verificación hacia una  actividad de diseño. ti id d d di ñ
    • Escribir las pruebas antes  Escribir las pruebas antes q que el código, ayuda a   g y aclarar nuestras ideas  sobre lo que tiene que  b l ti hacer el código. hacer el código
    • Las pruebas nos proveen  Las pruebas nos proveen de una red de seguridad  g basadas en pruebas de  regresión. ió Nos dan confianza para  Nos dan confianza para realizar cambios.
    • Como saber cuando  Como saber cuando empezar y terminar  empezar y terminar de escribir código. de escribir código
    • Caso de Estudio. Caso de Estudio Proceso de  P d Reposición de  i ió d 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= 100007777559,  100007777559 CodProducto CodProducto2=100007777560,  00007777560, CodProducto3=100007777561, TiPedido=NORMAL. TiP did 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 producto  proporciona 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  genera la guía de remisión para los  l í d i ió l productos solicitados.
    • Ubiquitous Language Solicitud de Reposición: Conjunto de  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  reposición para determinar la cantidad del  i ió d i l id d d l producto que se debe enviar al local que lo  solicitó. solicitó
    • Descomposición Funcional 1. Pedido Normal, 1 Producto, Catalogar 2. Pedido Normal, 1 P d t Re 2 Pedid N l Producto, Reponer e 3. Pedido Normal, Generar Guía de Remisión 4. Pedido E 4 P did Especial, 1 Producto, Aprobar i l P d t A b 5. Pedido Especial, 1 Producto, aprobar, catalogar, catalogar reponer 6. Pedido Normal, varios Productos 7. 7 Pedido Especial, varios productos, aprobar, Especial productos aprobar generación guía remisión
    • Infraestructura de Soporte Ayuda a entender los requerimientos y  Ayuda a entender los requerimientos y a proponer y validar un esbozo de la  arquitectura, se puede cambiar de  punto de vista posteriormente pero  punto de vista posteriormente pero es necesario empezar con algo que  de cierta perspectiva
    • Test para guiar la creación infraestructura de Soporte i f t t d S t
    • Código
    • Mock Objects Un sistema orientado a objetos  Un sistema orientado a objetos esta organi ado como una red de esta organizado como una red de  objetos colaboradores
    • Mock Objects Para probar un objeto, probamos  Para probar un objeto probamos las interacciones con los objetos las interacciones con los objetos  vecinos.
    • Verificar Expectativas Hamcrest es un framework para declarar criterios de  p correspondencia. Un Matcher reporta si un objeto cumple con un  determinado criterio. d t i d it i String s = "El color del carro es rojo"; 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ódigo
    • Métodos Compuestos Divida su programa en métodos que realicen  Divida 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 de  muchos métodos cada uno de pocas líneas de tamaño.
    • Código
    • Principio de Responsabilidad Única Ú i Cada objeto debe tener una sola  Cada 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ódigo
    • Maven Ejecución Pruebas. Ejecución Pruebas Integración Motores de Integración Continua Entorno headless en linux para no  interrumpir el escritorio. p Cobertura para Code Coverage. Calidad de Código. C lid d d Códi
    • Conclusiones El dominio esta estructurado en base a interfaces que  El 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  estado,  esto hace los programas más fáciles de  t d t h l á fá il d mantener y modificar. Es recomendable empezar con una prueba fallida y que  Es recomendable empezar con una prueba fallida y que ésta dirija  la implementación de la funcionalidad  q g j requerida desde algún objeto de interface.