Introducción a TDD. Enfoque de la Charla Presentar un ejemplo de principio a fin de una funcionalidad de un proyecto. Sin profundizar en las herramientas.

Presentación del tema: "Introducción a TDD. Enfoque de la Charla Presentar un ejemplo de principio a fin de una funcionalidad de un proyecto. Sin profundizar en las herramientas."— Transcripción de la presentación:

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 de una forma práctica.

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 Refacto r 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 obligatoriamente. - - Spikes para Código de terceros.

11 Nuestro ejemplo

12 Herramientas de Soporte Junit Jmock Cargo Selenium Spring Test Context Framework

13 Iteracion 0 Preparación de la infraestructura.

14 ¿Como comenzar?. - - Escoger la funcionalidad (feature) mas pequeña posible que la aplicación deba cumplir. - - Luego ir escogiendo funcionalidades de nuestro Product Backlog.

15 Nuestro ejemplo. Situación Inicial Situación Final

16 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

17 El primer Test Funcional Selenium

18 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

19 El primer Test Unitario. Ingreso a una cuenta. Test AccountTest no compila. Test AccountTest compila. Test AccountTest pasa el Test (Implementacion Falsa) Triangulación. Test AccountTest pasa el Test. Sin Refactor.

20 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.

21 Probando las situaciones de error. Segundo Test Unitario

22 - Retiro de una cuenta - Test con expectativa de excepción no compila - Test con expectativa de excepción si compila - Test con expectativa de excepción Pasa (Implementación) - Refactorizamos

23 Segundo Test Unitario Se deben probar todas las situaciones Realistas que pensemos que se pueden producir en la funcionalidad que probamos.

24 Tercer Test Unitario - Soporte de divisas EUR, USD, VNB - Test no compila - Pensar en el diseño del API desde el Test. (La divisa debe ir en el construtor) - El Test compila - Adaptación de tests a los cambios de diseño. - Ejecución total de la suite de tests

25 Tercer test unitario. Refactorizando y cambiando el diseño de la currency. Aplicando buenas practicas (Valores String) Pensar en el diseño (Añadir nuevo constructor a Account con el monto)

26 Probando un Servicio Servicio de Transferencia de dinero - El Test no compila. Primera aproximación - Pensar en el diseño. Se cambia el Test para invocar al API deseada - Implementamos. - Ejecutamos el Test. - Test de Regresión - Ejecutamos la suite de tests y arreglamos los fallos.

27 Probando un Servicio Los Tests son una red de seguridad contra la introducción de Bugs.

28 Refactorización de la Transfer Operation - Mejorando aun mas las APIs - Implementar Un builder - Ejecutar los Tests Probando un Servicio

29 Transferencias entre 2 monedas distintas. - Sin factor de conversión - Con factor de conversión. Primera aproximación. - Ejecutamos los tests. - Nuevamente los Tests impiden que un bug llegue a producción. Probando un Servicio

30 - Refactorización del Transfer Service. - Single Responsibilty Principle - Extraemos un nuevo tipo. Creamos el CurrencyService. Con TDD por supuesto. Probando un Servicio

31 En TDD existen dos momentos en los que se estudia el diseño de la aplicación. En la creación de los Tests y en la refactorización.

32 Mock Objects Introduciremos un Mock para la dependencia. ¿Qué es un Mock Object? Mock Hecho a mano. Jmock

33 JMOCK Nos permite con un lenguaje especifico de dominio definir Dobles de objetos para nuestros Test, y establecer las expectativas sobre estos objetos. Haciendo las dependencias Explicitas

34 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.

35 Probando un servicio - Refactorizamos CurrencyService - La responsabilidad de Conversión la pasamos al enum. - Escribimos los Tests - Implementamos.

36 Mock del DAO Creamos el AccountServiceTest pensando en sus dependencias. Que nos guíen al diseño correcto.

37 Test Driving el DAO. Test de Integración. ¿Qué es un test de integración? Spring Test Context Framework

38 Modificando Tests Agregamos la dependencia de Persistencia a la transferencia. Primero al Test.

39 TDD el controlador. Probando el Get de la funcionalidad. Probando el Post. Mock de HttpServletRequest

40 TDD el controlador. Un controlador es tan fácil de probar como cualquier otra clase.

41 Ejecutando el Test Funcional Cargo para iniciar el servidor. Selenium.

42 Dao JDBC Spring Test Context Framework

43 Revisando el Code Coverage Cobertura. Mvn site Mas que medir la cobertura por porcentaje. Estar conscientes de que hemos probado lo necesario.

44 Conclusiones Principales - - 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. - - Tdd acelera el proceso de desarrollo.

45 Bibliografía

46 Preguntas