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 utilizadas. El objetivo es clarificar el proceso de TDD de una forma práctica.

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.

¿Que es TDD?Practica de desarrollo de software

Test First + Refactor

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

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

El ciclo de TDD

Escribir un test Unitario que falle Hacer que

el test pase

Escribir un Test

Funcional Que falle

Conocido como el ciclo ROJO->VERDE-

>REFACTOR

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

¿Cuanto del código probar?

- - Probar TODO lo que tenga sentido probar.

- - No probar lo trivial obligatoriamente.

- - Spikes para Código de terceros.

Nuestro ejemplo

Herramientas de Soporte

JunitJmockCargoSeleniumSpring Test Context Framework

Iteracion 0

Preparación de la infraestructura.

¿Como comenzar?.

- - Escoger la funcionalidad (feature) mas pequeña posible que la aplicación deba cumplir.

- - Luego ir escogiendo funcionalidades de nuestro Product Backlog.

Nuestro ejemplo.

Situación Inicial Situación

Final

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

El primer Test Funcional

Selenium

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

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.

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.

Probando las situaciones de error.

Segundo Test Unitario

Segundo Test Unitario

- 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

Segundo Test Unitario

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

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

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)

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.

Probando un Servicio

Los Tests son una red de seguridad contra la introducción de Bugs.

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

Probando un Servicio

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

- Refactorización del Transfer Service.- Single Responsibilty Principle- Extraemos un nuevo tipo. Creamos el CurrencyService.

Con TDD por supuesto.

Probando un Servicio

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.

Mock Objects

Introduciremos un Mock para la dependencia.

¿Qué es un Mock Object? Mock Hecho a mano. Jmock

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

El uso de mocks

El uso de mocksSe puede establecer su necesidad en cualquiera de los dos tiempos de diseño. Escribir el Test, o la refactorización.

Probando un servicio

- Refactorizamos CurrencyService- La responsabilidad de Conversión

la pasamos al enum.- Escribimos los Tests- Implementamos.

Mock del DAO

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

Test Driving el DAO. Test de Integración.

¿Qué es un test de integración?Spring Test Context Framework

Modificando Tests

Agregamos la dependencia de Persistencia a la transferencia. Primero al Test.

TDD el controlador.

Probando el Get de la funcionalidad.Probando el Post.Mock de HttpServletRequest

TDD el controlador.

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

Ejecutando el Test Funcional

Cargo para iniciar el servidor. Selenium.

Dao JDBC

Spring Test Context Framework

Revisando el Code Coverage

Cobertura. Mvn site

Mas que medir la cobertura por porcentaje. Estar conscientes de que hemos probado lo necesario.

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.

Bibliografía

Preguntas