Seminario de Test Development Driven

Seminario de introducción a Test Driven Development organizado por Paradigma Tecnológico y javaHispano. El seminario fue impartido por Carlo Scarioni el 23 de Abril 2010
Mas info: http://www.paradigmatecnologico.com/historico/seminario-de-test-development-driven/

Transcript

1. Introducción a TDD
2. Enfoque de la Charla  Presentar un ejemplo de principio a fin de una funcionalidad de un proyecto. Sin profundizar en las herramientas utilizadas. El objetivo es clarificar el proceso de TDD.
3. Objetivos de la charla - - Introducir TDD como una alternativa viable al desarrollo tradicional. - - Crear cierta inquietud por profundizar mas en el tema. - - Exponer las ventajas que TDD tiene para el desarrollador. - - Explicar paso a paso como afrontar una funcionalidad con esta práctica.
4. ¿Que es TDD? Practica de desarrollo de software Test First + Refactor
5. ¿Que ventajas trae TDD al desarrollador? • Confianza en el funcionamiento. • Foco en el desarrollo. • Código mas limpio. (Buenas practicas de desarrollo y patrones). • Menos Bugs y mas localizados. • Documentación del código con los Tests. • Menos reinicio del servidor para probar.
6. Realizar el menor diseño posible antes de empezar. Solo lo necesario (Generalmente la Infraestructura de la aplicación). Los test guiarán el diseño. El ciclo de TDD
7. El ciclo de TDD Refactor Escribir un test Unitario que falle Hacer que el test pase Escribir un Test Funcional Que falle
8. Conocido como el ciclo ROJO->VERDE- >REFACTOR
9. ¿Cuanto tiempo pueden estar los tests en rojo? - - Test Unitarios deben pasar cuanto antes. - - Test funcionales tardarán mas en pasar. Y estarán en un ciclo distinto del BUILD. - - Nunca se subirán tests que fallan al repositorio de código fuente. - - Solo se desarrolla funcionalidad cuando exista un Test fallido que lo requiera.
10. ¿Cuanto del código probar? - - Probar TODO lo que tenga sentido probar. - - No probar lo trivial. - - Spikes paraThird Party. - - Cobertura.
11. ¿Como comenzar?. - - Escoger la funcionalidad (feature) mas pequeña posible que la aplicación deba cumplir. - - Luego ir escogiendo funcionalidades de nuestro Product Backlog.
12. Nuestro ejemplo. Situación Inicial Situación Final
13. Iteración 0
14. ¿Que es un test de aceptación o test funcional? Nos ayuda a definir exactamente la funcionalidad que queremos hacer. Un test define QUE queremos hacer, si importar realmente el COMO.
15.  No debe conocer los objetos internos del sistema.  Debe reaccionar ante eventos que se produzcan en la capa "visible" (GUI, LOG, etc). Usualmente haciendo un poll para ver si hay cambios. Test Funcional
16. Prueba la interacción entre distintos componentes del sistema, o entre el sistema y componentes externos. Por ejemplo con la Base de Datos, Con el sistema de ficheros, etc. Test Integración
17. Definimos el Test Funcional. Selenium
18. Definimos el Test Funcional. Selenium. Permite ejecutar Tests Directamente sobre la interfaz de usuario HTML, sobre un navegador en particular. Para esto la aplicación debe estar iniciada. El proceso de iniciar la apliciación debe ser automático, previo a la ejecución de los test, y terminado luego.
20. Definimos el Test Funcional. Este Test podrá estar sin pasar por mucho tiempo. Nos sirve como guía de la funcionalidad final que queremos conseguir.
21. Prueba comportamientos en aislamiento TOTAL respecto al resto del sistema. Prueba una y solo una caracteristica sin que los demas elementos del sistema afecten su ejecución. Test Unitario
22. El primer Test Unitario.  La primera abstracción que se nos ocurre es una Cuenta. En la que podemos depositar y sacar dinero.  Hacemos el test para depositar dinero
23. El primer Test Unitario. Hacemos el test compilar. Para eso creamos la clase Account y los métodos necesarios.
24. El primer test unitario. El Test Compila.
25. El primer Test Unitario Barra roja
26. El primer Test unitario.  Implementación Falsa VS Implementación obvia.  Pasamos el Test con implementación falsa.
27. Realizamos otro test que nos obligue a sustituir la implementación falsa. Esto es Triangulación en TDD El primer Test unitario.
28. Cambiamos la implementación El primer Test unitario.
29. La barra verde nuevamente El primer Test unitario.
30.  Cuando se sepa claramente la implementación obvia, aplicarla.  No es necesario siempre dar los pasos mas pequeños posibles.  Si la implementación obvia resulta no ser tan obvia, y al implementarla los test fallan. Hacer los pasos mas pequeños posibles. El primer Test unitario.
31. Es importante hacer tests para situaciones que esperamos produzcan un error. Probando los fallos.
32. Probando los fallos. Hemos creado por TDD lo siguiente en AccountTest y Account para el retiro de dinero. Sin embargo como requerimiento tenemos que no podemos dejar una cuenta a un numero negativo. Por tanto hay que comprobar que esto no se pueda dar.
33. Probando los fallos. Con esto decimos que esperamos que al producirse esta situación (Rerirar mas de lo que tenemos), se eleve la excepción WithdrawlException (Que aun no existe).
34. Probando los fallos. Creamos la excepción. Nuestro Test Compila
35. Probando los fallos. Ejecutamos el Test. Barra Roja
36. Añadimos la implementación obvia. Ejecutamos. Barra Verde. Probando los fallos.
37. Probando los fallos. Refactorizamos con un sencillo Extract Method. Ejecutamos. Barra Verde.
38. Continuando con Account. Soporte de Divisas La siguiente caracterisitac que deben soportar nuestras cuentas, es que pueden estar en EUR, USD o GBP. Comenzamos con el TEST.
39. Continuando con Account. Soporte de Divisas. Cuando uno crea un Test, la idea es imaginar el API mas correcto de lo que estamos creando. En este caso nos damos cuenta que una Cuenta DEBE tener una divisa. Por lo que la ponemos en le constructor.
40. Hacemos los cambios necesarios a Account para que compile y damos la solución obvia. Nuestros Tests anteriores ya no compilan (requerían constructor vacio). Cambiamos la construcción de las Accounts para el nuevo constructor. Ejecutamos los Tests. Barra verde. Continuando con Account. Soporte de Divisas.
42. Es muy importante ejecutar TODA la suite de Tests cuando se hacen cambios y refactorizaciones. Ya que aunque en el caso anterior se detectó en compilación el fallo (La falta de constructor). Muchas veces un cambió hará que cosas que asumiamos como correctas ya no lo sean. Y habrá que adaptar los Tests y el código a la nueva solución. Continuando con Account. Soporte de Divisas.
43. Refactorización Uno de los mas importantes "Code Smells", es el hecho de utilizar Strings para representar cosas que son mas que texto y tienen significado propio. En nuestro caso, el String que se pasa al constructor. Creamos un ENUM para representar nuestras divisas. Adaptamos los Tests. Barra Verde Continuando con Account. Soporte de Divisas.
44. Continuando con Account. Soporte de Divisas.
45.  Añadimos también, por comodidad un constructor que aparte de la divisa, se le pueda enviar también el balance inicial. Continuando con Account. Soporte de Divisas.
46. Probando el servicio de transferencia. Dejando Account a un lado, considerandolo terminado, nos centramos en el servicio de transferencia. Para nosotros una transferencia será sencillamente, retirar de una cuenta, y depositar en otra.
47. El primer test que se nos ocurre es hacer una transferencia entre 2 cuentas con la misma divisa. Probando el servicio de transferencia.
48. El código anterior es lo primero que se nos ocurre realizar. Sin embargo, viendo la interfaz del método transfer, los parámetros se prestan a confusión. ¿De que cuenta a que cuenta es la transferencia? Probando el servicio de transferencia.
49. Decidimos que un mejor diseño es encapsular la transferencia es su propio objeto y pasar este objeto al metodo transfer. Probando el servicio de transferencia.
50. La TransferOperation es mucho mas especifica. Creamos las clases que nos faltan Probando el servicio de transferencia.
51. Ejecutamos nuestro Test. Barra Roja!!. Probando el servicio de transferencia.
52. Haciendo una inspección de que puede estar fallando, nos damos cuenta que el error no esta en el servicio, ni en el Test.. sino en Account (Podriamos hacer un mock temporal de la clase account y ver que se llaman al deposit y withdrawal correctamente. Pero el servicio es muy simple y resulta obvio). Clase que habiamos dada por terminada. Vemos que el problema está en el metodo deposit. Por no haber triangulado lo suficiente en las pruebas. Probando el servicio de transferencia.
53. Prueba de Regresión. Se reporta un Error (Bug) por una funcionalidad dada por cerrada y que por falta de input no se hizo el test adecuado. Normalmente la falta de input es por requerimientos no entendidos completamente. En nuestro caso es que no hicimos todas las pruebas que debimos.  Probando el servicio de transferencia.
54. Vamos a AcountTest. y agregamos un Test para el error que hemos obtenido. Barra Roja Probando el servicio de transferencia.
55. Vamos a la clase Account e implementamos de forma correcta (que al menos pase este test que es lo que entendemos por correcto) el metodo deposit. Probando el servicio de transferencia.
56. Ejecutamos nuestro Test AccountTest. Barra Roja otra vez. Probando el servicio de transferencia.
57. Vemos que ahora el balance es null en deposit cuando aun no se ha depositado nada. La ejecución de los Tests, siempre va a capturar comportamientos no deseados como este, si se hacen los tests correctos. Corregimos Account y ejecutamos el Test. Barra Verde. Al fin. Probando el servicio de transferencia.
58. Regresamos al punto donde realmente estabamos. En TransferTest. Lo ejecutamos. Barra Verde. Probando el servicio de transferencia.
59. Refactoring. La forma de construir la TransferOperation no es del todo agradable. sustituimos los setters actuales por un semi-builder mas intutitivo y comodo, definido con un DSL propio. Cambiamos el Test a como realmente queremos que luzca la llamada. Probando el servicio de transferencia.
60. Cambiamos el codigo de TransferOperation, Ejecutamos el Test, Barra Verde.
61. Transferencias entre 2 monedas distintas. Diseñamos nuestro Test. Primera aproximación. Sin factor de conversión. Barra Verde Probando el servicio de transferencia.
62. Transferencias entre 2 monedas distintas. Con factor de conversión. Primera aproximación Probando el servicio de transferencia.
63. Transferencias entre 2 monedas distintas. Con factor de conversión. Primera aproximacion. Hacemos compilar el codigo. Ejecutamos. Barra roja Probando el servicio de transferencia.
64. Transferencias entre 2 monedas distintas. Con factor de conversión. Primera aproximación. Implementamos. Probando el servicio de transferencia.
65. Transferencias entre 2 monedas distintas. Con factor de conversión. Primera aproximación. Ejecutamos los Tests. Barra Roja Probando el servicio de transferencia.
66. Transferencias entre 2 monedas distintas. Se arregla el bug que se acaba de introducir. Ejcutamos los Test. Barra Verde. (Ojo tambien habría que verificar, con test que los valores están metidos en el mapa de conversionRates) Probando el servicio de transferencia.
67. Transferencias entre 2 monedas distintas. Refactorización SRP. Necesitamos otro servicio, Currency Service que se ocupe de la conversión. TransferService solo sabe de transferencias. Probando el servicio de transferencia.
68. Creamos la implementación extrayendo una clase nueva de TransferServiceImpl.
69.  Incluimos la dependencia en Transfer Service para que utilice la nueva dependencia.
70. Ejecutamos CurrencyTest. Barra Verde. Sin emabrgo luego de una amplia refactorización como la hecha es necesario ejecutar toda la suite de tests para verificar que todo está correcto.
71. Transfer Test se ha roto con la refactorización, ya que se ha incluido una nueva dependencia que no habiamos considerado cuando hicimos el servicio. Debemos adaptar nuestro Test a esta nueva casuistica.
72.  En el caso anterior en realidad se debía hacer el test antes de añadir la dependencia a la clase implementación.  Siempre se debe atender primero al Test según los requerimientos y el comportamiento que se quiere lograr
73. Mock Objects  Introduciremos un Mock para la dependencia.  ¿Qué es un Mock Object?
74. Mock Object. Mock hecho a mano
75. JMOCK Nos permite con un lenguaje especifico de dominio definir Dobles de objetos para nuestros Test, y establecer las expectativas sobre estos objetos.
76. Mock con Jmock. Y expectativas. Ejecutamos todos los tests. Barra verde
77. El uso de mocks El uso de mocks Se puede establecer su necesidad en cualquiera de los dos tiempos de diseño. Escribir el Test, o la refactorización.
78. Refactorizando CurrencyService. Ese mapa de mapas es muy lioso. Se nos ocurre mover la responsabilidad de saber el rate de cambio a la propia divisa.
79.  Para hacer esto decidimos también conversión establecer Rates a una divisa única y utilizar esta para los cambios. Usamos el Dólar.
80. Escribimos los Tests (En realidad se escribieron 1 a 1 estos tests). Y Ejecutamos, Barra Roja.
81. Implementamos
82. Ejecutamos los tests. Green Bar Refactorizamos CurrencyService
83. Persistiendo los cambios Persistiendo los cambios. Servicio de persistencia de cuentas. Mock del Dao en Las transferencias. TDD. AccountService debe permitir persistir cuentas. No compila. Añadimos una nueva propiedad a la clase Account. El identificador. AccountNumber. Aqui incluimos el mock antes de implementar nada. Sabemos que por buena practica el Servicio no irá directo contra Repositorio.
84. Persistiendo los cambios  - Diseñamos el Test con las dependencias en Mente.  - Nos damos cuenta de la necesidad de un identificador de cuenta. Y lo incluimos en nuestro Test.  - Siempre pensar en como queremos invocar a nuestras APIs
85. Lo hacemos compilar. Implementamos en account service. Ejecutamos el test. Barra Verde.
86. Test Driving el DAO. Test de Integración. Ahora haremos la implementación del DAO guiado por tests. Exactamente igual que como hasta ahora. Solo que ahora interactuamos con elemento externo. La Base de Datos, o sistema de ficheros. Pero empecemos por el test.
87. Utilizaremos el poderoso Spring Test Context para las pruebas de integración. (Las siguientes pruebas se hicieron 1 a 1).
89. Implementamos (En realidad lo anterior se hizo test a test. Pero para recortar lo ponemos todo de hecho con la primera ejecución nos dimos cuenta que Account debía ser serializable y debiamos implementar el equals y el hashcode para comparar Accounts) .
91. En algunos casos, los tests de integración son bastante mas lentos que los tests unitarios como vemos. Ejecutamos la suite entera de tests
92. Persistiendo las transferencias El servicio de transferencias ahora mismo no persiste los datos. Debemos añadir esto a nuestra aplicación. Lo añadimos en el Test, lo hacemos compilar, y lo implementamos en el servicio. Con el mismo procedimiento paso a paso hecho hasta ahora. Al final obtenemos el siguiente resultado. Obteniendo la barra verde.
96. Ejecutamos. Barra Verde
97. TDD el controlador. Se basa en los mismos procedimientos que el probar las otras capas. Centrarnos en la funcionalidad requerida, y simular los demas componentes. Las dependencias. Sabemos que trabajaremos con Controllers de Spring. Lo primero que haremos será la funcionalidad para presentar el formulario.
99. TDD El controlador. Lo hacemos compilar.Ejecutamos. Barra Roja
101. TDD el controlador Implementamos. Ejecutamos el Test. Barra Verde. En principio no hay refactorización que hacer.
102. TDD el controlador. El submit del formulario Mocking HttpServletRequest.
103. TDD el controlador. Implementamos. Barra Verde.
104. Ejecutamos la Suite Entera de Tests. Barra Verde.
105. El test funcional. Creamos las JSPs requeridas segun nuestros Test, nuestro controller y nuestro conocimiento de Spring MVC. Transfer.jsp
106. transferResult.jsp
107. Todo dentro del Test  El Test funcional idealmente es capaz de iniciar todo su entorno. En nuestro caso iniciamos el Tomcat.
108. Utilizamos Cargo para controlar el servidor.
109. Preparando para el Test Funcional
110. Las 2 fases del BUILD
111. Ejecutando el Test Funcional. Incluimos Un setup Completo en el test que inicia el servidor tomcat.
112. Ejecutamos la Suite Entera  Incluyendo Funcionales
113. Las 2 Fases del BUILD  En un entorno de integración continua.  Mvn test: Ejecuta los Tests unitarios, se ejecutara en cada momento  Mvn integration-test: Ejecuta los Tests funcionales. 2 veces al dia.
114. Revisando el Code Coverage  Cobertura.  Mvn site  Mas que medir la cobertura por porcentaje. Estar conscientes de que hemos probado lo necesario.
115. Reporte del Ejemplo PACKAGE CLASES LINE COVERAGE ALL PACKAGES 16 75% ORG.PT.TDD 1 92% ORG.PT.TDD.DAO 2 75% ORG.PT.TDD.DOMAIN 3 69% ORG.PT.TDD.EXCEPTION 3 50% ORG.PT.TDD.FORM 1 100% ORG.PT.TDD.SERVICE 6 90% Cobertura 136/179 15/20 26/28 64/92 6 12 18/20 7/7
116. Cobertura
117. Cobertura
118. Conclusiones - - TDD nos ayudan a mantener el foco de lo que queremos desarrollar. - - TDD nos sirve como red de seguridad para atrapar Bugs lo antes posible. - - TDD nos da seguridad de que lo que desarrollamos funciona.
119. Bibliografía
120. Preguntas