8. Introducción Se uso un estilo TDD iniciado en Londres a comienzos de los 2000 (Steve Freeman & Nat Pryce) caracterizada por el enfoque end-to-end y por el énfasis especial en la comunicación entre objetos.
9. Por qué adoptamos agile? “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”
19. Desarrollo Incremental/Evolutivo Dividir el trabajo en periodos fijos, en cada uno de los cuales se diseña, implementa, prueba y despliega funcionalidad. El desarrollo incremental construye el sistema característica por característica. El desarrollo iterativo progresivamente refina la implementación hasta que sea lo suficientemente buena en respuesta a retroalimentación constante..
20. Retroalimentación Agile nos permite aplicar ciclos de retroalimentación organizando nuestros proyectos en ciclos anidados que duran desde segundos a meses.
24. Los ciclos más externos están enfocados en la organización y el equipo.El proceso de pruebas ya no es una actividad final de verificación sino que va a la par con las tareas de desarrollo.
25. División Funcional Una técnica fundamental del desarrollo incremental es dividir la funcionalidad de tal manera que se pueda construir característica por característica.
26. División Funcional Cada característica a implementar se denominada un “slice” y debe involucrar todas las partes relevantes del sistema.
27. Slices Cada “slice” debe ser significativo y lo suficientemente concreto para determinar cuando estará terminado Y lo suficientemente pequeño para estar enfocado en un único concepto y sea implementado rápidamente.
28.
29. Niveles de Pruebas Aceptación: Trabaja el sistema en su conjunto? Integración: Nuestro código trabaja contra código que no podemos cambiar? Unitario: Nuestros objetos hacen lo correcto, son convenientes para trabajar?
30. Niveles de Pruebas Separar las pruebas que miden progreso de aquellas que capturan regresiones.
31. Pruebas End-to-End Ejercitan al sistema desde el exterior a través de sus interfaces externas. Esto puede significar bastante esfuerzo en lograrse, pero se tiene que hacer de todas maneras durante el ciclo de vida del software. Con una combinación adecuada de automatización y pruebas end-to-end nuestro producto puede estar siempre integrado y listo para el despliegue.
33. Walking Skeleton Es la implementación de la funcionalidad mínima útil que pueda ser construida, desplegada y probada end-to-end. Luego construiremos incrementalmente el producto slice por slice.
34. Walking Skeleton El primer test end-to-end ayuda a visualizar el contexto del proyecto para trazar el panorama de su solución y a tomar decisiones esenciales antes de escribir algún código. Pasos para identificar una característica mínima útil: http://blog.jbrains.ca/permalink/three-steps-to-a-useful-minimal-feature
35. ¿Cómo aseguramos la calidad de la implementación a medida que construimos incrementalmente?
37. Diseño Guiado por Pruebas Como usamos las pruebas como guía para obtener sistemas orientados a objetos? The big idea is “messaging” […] The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. —Alan Key
39. Diseño Guiado por Pruebas El sistema es construido creando y ensamblando objetos de tal manera que puedan enviarse mensajes entre sí. El comportamiento del sistema es resultado de ésta composición. Esto permite cambiar el comportamiento agregando y removiendo instancias o ensamblando diversas combinaciones.
40. Si escribimos pruebas durante todo el proceso de desarrollo podemos crear un red de seguridad que nos dará confianza para realizar cambios.
47. Acceptance Test Driven Development Están dirigidas por las historias de usuario y el diseño conceptual, es todo muy sistemático. Se puede saber con precisión cuando se han terminado de implementar correctamente.
49. Acceptance Test Driven Development Empezamos construyendo una prueba de aceptación que ejercite la funcionalidad que necesitamos implementar. Mientras no pase la prueba de aceptación se asume que el sistema todavía no implementa esa característica.
50. Acceptance Test Driven Development El ciclo externo es una medida demostrable de progreso y el conjunto de pruebas nos protege contra fallas de regresión cuando cambiemos el sistema.
54. Se inicia con un evento externo que ejercite el comportamiento que queremos implementar, éste se propaga a través del código objeto por objeto, hasta alcanzar un efecto visible. En los límites de nuestro sistema, necesitamos escribir uno o más objetos para manejar esos eventos. A medida que vamos avanzando con la implementación descubriremos que esos objetos necesitan servicios de soporte de otros objetos del sistema para cumplir sus responsabilidades.
55.
56.
57. A las capas intermedias, pasando por el modelo del dominio central
60. Relaciones entre objetos En este esquema basado en la comunicación debemos diseñar la interface de un colaborador basándonos en su uso pretendido antes que en su implementación. Esto lleva a un proceso de descubrimiento donde las interfaces de los objetos colaboradores son traídas a la existencia basadas en los requerimientos inmediatos dirigidos por necesidad.
61. Representaciones de Relaciones En lenguajes modernos como Java se representan las relaciones como interfaces. Esto nos permite modelar las interacciones entre objetos sin necesidad de contar con una implementación concreta.
62. Si no existen implementaciones concretas, como validamos en nuestras pruebas las interacciones entre los objetos?
63.
64. Mock Objects Las pruebas usando mock objects definen un conjunto de restricciones que especifican que mensajes los objetos pueden enviar y la forma en que los mensajes deben ser enviados.
69. Protocolos de Comunicación Una interface define si dos componentes pueden relacionarse entre sí Un protocolo describe si dos objetos pueden trabajar juntos.
70. Protocolos de Comunicación Los mock objects nos permiten visualizar éstos protocolos. Son una herramienta tanto para descubrir los roles que desempeñan los objetos así como para describir sus interacciones cuando revisamos el código.
71.
72. Importancia de los diagnósticos Siempre debemos verificar que el test falle “correctamente” revisando los mensajes de falla. Si la prueba falla de una manera inesperada podemos concluir que hemos malentendido algo o el código no está correctamente terminado.
73. Cuando tengamos la falla “correcta” verificaremos que el diagnostico será útil si el código falla posteriormente.
76. Implementación Cuando iniciamos una nueva área de codificación podemos suspender temporalmente nuestro sentido de diseño y escribir código sin imponerse mucha estructura. Luego cuando encontremos que nuestro código se vuelve bastante complejo de entender debemos empezar a mejorarlo.
77. Refactoring El objetivo es mejorar el código de tal manera que represente mejor las características que implementa haciéndolo más mantenible y para facilitar la adición de nueva funcionalidad.
78. SRP Cada objeto debe tener una sola responsabilidad claramente definida. Nuestra heurística espoder describir lo que hace elobjeto sin usar conjunciones (y / o). Cuando agregamos comportamiento a un sistema este principio nos ayuda a decidir si debemos extender un objeto existente o si debemos crear un nuevo servicio a ser llamado.
79. Descubriendo Roles Una vez detectada una violación a SRP se debe descubrir algún colaborador que lleve a cabo el rol necesitado moviendo la implementación si el código ya existe.
83. Internals vs. Peers Si exponemos lo interno de un objeto a través de su API, sus clientes pueden terminar haciendo parte de su trabajo. Podemos tener comportamiento repartido en demasiados objetos (que estarían acoplados) incrementando el costo de mantenimiento debido a los cambios ahora estarán repartidos en el código.
90. Arquitectura Emergente Como identificar diseño oculto en código existente Composed Method & SLAP http://www.ibm.com/developerworks/java/library/j-eaed4.html Métricas y visualizaciones ayudan a identificar partes importantes de nuestro código permitiendo extraerlos como elementos de diseño de primera clase. Recolección de Patrones Idiomáticos http://www.ibm.com/developerworks/java/library/j-eaed9/index.html
![Agenda ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)