Hacer un sistema, sin probar, es lanzarlo al precipicio. Las pruebas son fundamentales, pero claro, probar sin un método es lo mismo que no probar, es probar sólo una parte del sistema y dejar lo demás al azar. TDD es una técnica de eXtreme Programming con la que las pruebas y el código se escriben a la vez. No antes cuando el sistema sólo es una abstracción. No después cuando en realidad ya da flojera escribirlas. A la vez que se escribe el código, van las pruebas. TDD es un método ágil y eficaz de lograr un sistema Probado, y Funcional.

1. Cómo hacer TDD
Javier Novoa C.
1

2. Contenido
●
●
●
●
¿Cómo programamos?
¿Qué buscamos?
Test Driven Development.
Un ejemplo.
2

3. Cómo solemos programar
3

4. 4

5. 5

6. ¿Qué buscamos?
Estar seguros que lo que programamos
es correcto.
●
•
●
●
●
Evitar bugs innecesarios, si nuestro
código estuviera PROBADO al 100%.
No tener incertidumbre al hacer cambios.
Un 'documento' (útil) que nos explique
el código (a nosotros programadores).
Hacer más y mejor diseño e ingeniería,
y menos burocracia.
6

7. Test Driven Development
Básicamente consiste en:
●
Probar cada línea de código que escribimos...
●
Probar cada cambio, cada corrección de un bug...
●
Escribir las pruebas antes que el código (¿¿??)
7

8. 8

9. ¡No hagas esto! Haz pruebas.
9

10. ¡Sigue un orden!
Empieza por hacer Pruebas Unitarias
10

11. Pruebas Unitarias
Normalmente haces estas pruebas:
●
●
●
Cuando te acuerdas (o te recuerdan) que
debes probar
Pero no pruebas TODO tu código, sólo los
escenarios principales.
Terminas siendo laxo para probar
realmente
11

12. TDD no es Unit Testing a secas
12

13. Test First Programming
Los que llegan a hacer esto:
●
●
●
'Diseñan' previamente su sistema a través
de todas las pruebas unitarias que debe
pasar
Luego programan para hacer pasar sus
pruebas
Terminan probando solo el diseño inicial,
y no el sistema final
13

14. TDD no es Test First Programming a secas
14

15. Qué es TDD
●
Sí es hacer Unit Tests
●
Sí es hacer Test First Programming
●
PERO todo dentro de un ciclo de desarrollo
Extremo (XP): el Test Driven Development
(o TDD)
15

16. El Ciclo del TDD
16

17. Las Tres Leyes de TDD
1) No escribir nada de código hasta escribir
una prueba unitaria (que va a fallar porque ni
código hay).
2) No escribir más de una prueba unitaria que
falle.
3) No escribir más código que el necesario
para que la actual prueba que falla, pase.
17

18. Ventajas del TDD
●
Certeza.
●
Reducción de bugs.
●
Confianza.
●
Documentación.
●
Mejor diseño.
18

19. Un ejemplo...
https://github.com/jstitch/gift_circle
19

20. En resumen
●
●
●
●
TDD permite lograr un código probado
muy cercano al 100%.
Para hacer TDD bien, hay que seguir las
3 leyes.
Es un método de trabajo para
programadores con un ciclo de escritura
de código/pruebas muy corto.
Permite un diseño más profesional del
código que escribimos.
20

21. ¿PREGUNTAS?
21

22. GRACIAS
JAVIER NOVOA CATAÑO
Twitter @JaviStitch
jstitch@gmail.com
https://github.com/jstitch
22