1.
TDD
 Agenda
 TDD for Dummies
 Porqué NO?.
 Porqué SI?.
 Algunas técnicas
 Dejemos a los que saben!

2.
TDD for Dummies
 TDD = Test Driven Development
 Es una técnica de desarrollo de software
 Se hizo conocida como parte del la ola “Extreme
Programming” (circa 2000)
 Sirve como apoyo a la fase de diseño (no la
reemplaza)
 Sirve como método de documentación (no la
reemplaza)

3.
Porqué No?
 “Programar pruebas lleva demasiado tiempo”
 “Correr las pruebas lleva demasiado tiempo”
 “No es mi trabajo probar”
 “No sé exactamente qué hace mi código, así que no
puedo probarlo”
 “¡Pero si compila!”

4.
Porque Si?
 Menor sobrecarga de trabajo
 Confianza en cambiar las cosas
 Puedo responder:
 Hace mi código lo que yo digo que hace?
 Lo hace TODO el tiempo?
 Puedo confiar en los pasos anteriores?
 Existe documentación de lo que intente

5.
Algunas técnicas
 Right – BICEP
• Right
• Boundary
• Inverse Relationships
• Cross­check
• Error condition
• Performance

6.
Boundary
 CORRECT
 Conformance
 Ordering
 Range
 Reference
 Existence
 Cardinality
 Time

7.
Inverse Relationships & Cross­Check
 Probar si el método inverso nos devuelve el valor
original
 Probar que otro algoritmo (ya probado, o no)
devuelva los mismos resultados que el nuestro.

8.
Error Conditions & Performance
Forzar condiciones de error
 Correr con poca memoria
 Con poco espacio en el disco
 Desconectar la red
 Resolución de video errónea.
Tener en cuenta la Performance
 En una ejecución no se notan diferencias, ¿y en
1000?

9.
Mock
 Las pruebas deberían ser unitarias, pero ¿qué pasa
si mi unidad a probar depende de otra?
 Mock: Un “Doble de Riesgo” que provee la
funcionalidad de las unidades que necesitamos.

10.
Mock – Cuando?
 El objeto real no es determinístico
 El objeto real es costoso de crear
 El objeto real tiene un comportamiento dificil de
disparar (error de red, schdulers)
 El objeto real es lento
 El objeto real es una interfaz de usuario
 El objeto real no existe todavía

11.
TDD
 Escribir los tests
 Correr todos los tests y ver dónde fallan
 Escribir el código de los métodos
 Correr los tests y ver dónde fallan
 Refactorizar el código

12.
TDD
Dejemos a los que saben.