Este documento presenta una introducción al desarrollo guiado por pruebas (TDD), describiendo sus conceptos básicos, propósitos, proceso de aplicación a través de ejemplos, beneficios y limitaciones. También discute temas como pruebas unitarias, refactorización, áreas de aplicación como back-end, front-end y bases de datos, y recomendaciones para la implementación exitosa de TDD.

1. Francisco Grau - 2014 @graux

2. • Conceptos Iniciales
• Mitos entorno a TDD
• Qué es TDD y de donde viene
• TDD: Por qué y cual es su propósito
• Entender el MANTRA de Test-Driven Development
• Cómo se aplica, ejemplo práctico
• Una herramienta más en el ciclo de desarrollo ágil
• Áreas de aplicación
• Otros aspectos a tener en cuenta
• TDD en el entorno de desarrollo cuotidiano
• Referencias e información adicional
Francisco Grau - 2014 @graux

3. • Pruebas Unitarias (set up, validate, execute, clean up)
• Metodologías Ágiles
• Refáctoring
• Deuda Técnica (technical debt)
• Criterios de calidad de código
• X-Driven Development
Francisco Grau - 2014 @graux

4. • No sirve para GUIs o Front-end
• No sirve para Leguajes de Scripting
• No se puede probar programas multi-hilos
• No se pueden probar bases de datos
• No se debe probar software de terceros **
• No se pueden probar objetos distribuidos
Francisco Grau - 2014 @graux

5. • Proceso de desarrollo: “Clean code that works” (Ron Jeffries)
• Sistemas contabilidad – Smalltalk + alta cobertura de pruebas
• En 2000-2003, Kent Beck como parte de eXtreme Programming
• Evolución junto con las metodologías ágiles
• Requiere disciplina y asimilación por parte del equipo de
desarrollo
• Curva de aprendizaje
• Organización tiene que aceptar la inversión
Francisco Grau - 2014 @graux

6. • Buen código: sin fallos, limpio, simple, organizado, mantenible…
• Huir de ciclos destructivos:
Estrés Pruebas
• Conseguir ciclos virtuosos:
Pruebas Seguridad
• Impacto de cambios en código predictibles
• Seguridad y Confianza
• Menos Bugs ***
• Entregables más continuos y fiables (agilidad)
Francisco Grau - 2014 @graux

7. RED
Compilador / Fallo
GREEN
REFACTOR
Francisco Grau - 2014 @graux
NUEVA PRUEBA

8. Las reglas:
1. Nuevo código sólo se escribe cuando una prueba ha fallado *
2. Eliminar todo tipo de duplicación
3. Escribir las pruebas uno mismo/a
4. Habilidad de introducir pequeños cambios rápidamente
5. Diseño orientado a alta cohesión, componentes no acoplados y que faciliten las pruebas
Recomendaciones:
1. Empezar con Programación en Parejas
2. Poco a poco, paciencia, no abrumarse los resultados iniciales y sin saltarse pasos (al principio)
3. Actitud positiva y no sobre-complicar las pruebas
4. Cierta experiencia con Patrones de Diseño
* Excepciones: refactoring, código de pruebas, etc.
Francisco Grau - 2014 @graux

9. Herramientas:
• Papel y bolígrafo !!!
• Compilador o validador (Lint)
• Framework de pruebas (xUnit)
Pasos:
1. Listar requisitos
2. Empezar por el más simple, menos dependencias, más rápido para “verde”
3. Crear test que falle
4. Arreglar errores de compilación
5. De rojo a verde è rápido
6. Eliminar Duplicaciones / Refactoring
Francisco Grau - 2014 @graux

10. Técnicas de implementación (conseguir verde):
1. Falsear (Fake it)
2. Implementación obvia
3. Triangulación (eliminación de duplicación entre pruebas y código)
Francisco Grau - 2014 @graux

11. • TDD no soluciona problemas de procesos, pero ayuda
• El contexto lo es todo, TDD no es una religión
• Equipos ágiles acogen los cambios, TDD los asimila
• Antes de {refactorizar, mejorar rendimiento, cambio versiones,
cambio de integración} èTDD
• Bug en lógica de negocio è nuevo test que falle è “verde” è
eliminad duplicidad
• TDD no se debe aplicar a medias o sin disciplina
Francisco Grau - 2014 @graux

12. • Back-end / Front-end?
• APIs?
• Bases de Datos?
• Video-juegos?
• Start-ups / Enterprise?
• Librerías y Frameworks
Francisco Grau - 2014 @graux

13. • Qué probar?
• Qué son buenas pruebas? Que es TDD para cada persona/
equipo?
• TDD en proyectos ya existentes (extensos)
• Más Pruebas: Funcionales, Integración, Compatibilidad y
automatización (TDD no es una técnica de pruebas)
• Refactoring requiere de patrones de diseño (para pruebas y para
lógica de aplicación)
Francisco Grau - 2014 @graux

14. • Fixtures, Fakes y Mocks
• Acelerar las pruebas creando “test suites”.
• Más Velocidad è Más pruebas
• Entorno de pruebas integrado (xUnit+IDE, Codeception)
• Qué ocurre con “si funciona no lo toques”?
• Individualmente: Dejar última prueba fallando
• Equipo: Integración Continua + Todas las pruebas pasan
Francisco Grau - 2014 @graux

15. • Test-Driven Development: By Example – Kent Beck – Addison-Wesley
• TDD Wikipedia: http://en.wikipedia.org/wiki/Test-driven_development
• Introduction to Test Driven Development - http://www.agiledata.org/essays/tdd.html
• Should a startup use TDD: http://www.redhills.ie/blog/should-a-startup-use-tdd/
• Making better games with TDD:
http://gamesfromwithin.com/backwards-is-forward-making-better-games-with-test-driven-development
• Test-Driven Development with JavaScript: http://enterprisewebbook.com/ch7_testdriven_js.html
• Let’s Code: Test-Driven JavaScript: http://www.letscodejavascript.com/
Francisco Grau - 2014 @graux