Tips y buenas prácticas sobre Test Driven Development. Contenido introductorio para todas aquellas personas que quieran mejorar sus skills como programadores.

1. Introducción a TDD
Test Driven Development
@JuanmaGomeR

2. ¿Qué es TDD?
Es una técnica que consiste,
básicamente, en apoyarnos en un test
automatizado existente para
desarrollar nuestra lógica de negocio
@JuanmaGomeR

3. ¿Un test existente?
Sí. Pero no reutilizado, sino uno nuevo
que escribamos nosotros
@JuanmaGomeR

4. El ciclo de TDD
RED
REFACTO
R
GREEN
@JuanmaGomeR

5. RED
Escribimos un test automático que,
cuando lo ejecutemos, falle (sale en
rojo)
RED
@JuanmaGomeR

6. GREEN
Escribimos el MÍNIMO código que haga
pasar el test automático que hemos
escrito (sale en verde)
GREEN
@JuanmaGomeR

7. REFACTOR
Modificamos la apariencia de nuestro
código, pero nunca su
comportamiento. Aplicamos patrones
de diseño, DRY, SOLID...
REFACTO
R
@JuanmaGomeR

8. ¿Cómo TDDear?
Cada test representa un estado de mi
sistema
@JuanmaGomeR

9. ¿Cómo TDDear?
El SUT entra en el sistema y modifica
su estado
@JuanmaGomeR

10. ¿Cómo TDDear?
Por tanto, definimos estado inicial,
estado que esperamos, y obtenemos el
estado final
@JuanmaGomeR

11. ¿Cómo TDDear?
Comparamos estado esperado con
estado final (creado por el SUT)
@JuanmaGomeR

12. Baby Steps
El primer test será el que ejemplifique
el caso más sencillo. Cuando lo
pasemos, habremos dado soporte a
una primera casuística
@JuanmaGomeR

13. Baby Steps
En el siguiente test, daremos un pasito
adelante, planteando una casuística un
pelín más compleja, el siguiente paso
natural
@JuanmaGomeR

14. Baby Steps
Y así seguiremos avanzando, de forma
que consigamos abarcar la mayor
cantidad de casuísticas posibles
@JuanmaGomeR

15. Triangulación
Llegará un momento en que
triangulemos para encontrar un patrón
de comportamiento
@JuanmaGomeR

16. Triangulación
Este patrón nos llevará al diseño
definitivo del algotirmo que buscamos
@JuanmaGomeR

17. Tras cada refactor
Es esencial pasar de nuevo los tests
tras cada refactor para ver que nada
ha dejado de funcionar
@JuanmaGomeR

18. Si otro día modifico lógica de negocio
Compruebo primero los tests
@JuanmaGomeR

19. Si otro día modifico lógica de negocio
Modificar los tests afectados por los
nuevos requerimientos (si fuera
necesario)
@JuanmaGomeR

20. Si otro día modifico lógica de negocio
Una vez definidos los nuevos tests,
escribir la nueva lógica de negocio
@JuanmaGomeR