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.
El ciclo de TDD
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
Escribir un Test
Funcional Que
falle
Escribir un
test Unitario
que falle
Hacer que el
test pase
Refactor
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
Junit
Jmock
Cargo
Selenium
Spring 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
Test Funcional
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.

El primer Test Funcional

Selenium
Test Unitario
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.
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.
El primer Test unitario.



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.
Segundo Test Unitario
Probando las situaciones de error.
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.
Probando un Servicio
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.
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 mocks
Se 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
Descargar

Slide 1 - presentacion-tdd