Introducción a TDD
description
Transcript of Introducción a TDD
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 UnitarioSe 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 ServicioServicio 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
JMOCKNos 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