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.
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
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
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
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
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
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