Aw Tdd Mocks Design 1.2

774 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
774
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Aw Tdd Mocks Design 1.2

  1. 1. Diseño guiado por Mocks y Test Unitarios juancarlos.vergara@agile‐works.com
  2. 2. Agenda • Introducción • Caso de Estudio Caso de Estudio • Conclusiones
  3. 3. 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
  4. 4. Los desarrolladores no  Los desarrolladores no entendemos  completamente la  tecnología a usar,  t l í necesitamos aprender en  necesitamos aprender en el camino.
  5. 5. 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. 
  6. 6. 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.
  7. 7. 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
  8. 8. Para aplicar ciclos de  Para aplicar ciclos de retroalimentación, se  organizan los proyectos  como un sistema de  it d ciclos anidados. ciclos anidados
  9. 9. 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
  10. 10. 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.
  11. 11. Cada ciclo  controla  Cada ciclo controla diferentes aspectos del  diferentes aspectos del sistema y del proceso  y p de desarrollo.
  12. 12. Los ciclos más internos  Los ciclos más internos están enfocados en el  están enfocados en el detalle técnico.
  13. 13. Los ciclos más externos  Los ciclos más externos están enfocados en la  organización y el equipo.
  14. 14. 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
  15. 15. 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.
  16. 16. Simplicidad  Simplicidad requiere esfuerzo:  requiere esfuerzo: Refactoring
  17. 17. Las pruebas automáticas,  Las pruebas automáticas nos protegen contra  nuestros errores a medida  did que mejoramos nuestro  que mejoramos nuestro código
  18. 18. 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
  19. 19. TDD trata de  TDD t t d cambiar esta  situación. situación
  20. 20. 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 ñ
  21. 21. 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
  22. 22. 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.
  23. 23. Como saber cuando  Como saber cuando empezar y terminar  empezar y terminar de escribir código. de escribir código
  24. 24. Caso de Estudio. Caso de Estudio Proceso de  P d Reposición de  i ió d Productos
  25. 25. • 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.
  26. 26. • COMMAND: Reposicion, COMMAND: Reposicion,  CodLocal=0052,CodProducto1= 100007777559,  100007777559 CodProducto CodProducto2=100007777560,  00007777560, CodProducto3=100007777561, TiPedido=NORMAL. TiP did NORMAL
  27. 27. 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.
  28. 28. 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.
  29. 29. 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ó
  30. 30. 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
  31. 31. 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
  32. 32. Test para guiar la creación infraestructura de Soporte i f t t d S t
  33. 33. Código
  34. 34. 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
  35. 35. Mock Objects Para probar un objeto, probamos  Para probar un objeto probamos las interacciones con los objetos las interacciones con los objetos  vecinos.
  36. 36. 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)); ( ( ));
  37. 37. Código
  38. 38. 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.
  39. 39. Código
  40. 40. 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
  41. 41. Código
  42. 42. 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
  43. 43. 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.

×