TDD

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

  

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)

  

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!”

  

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

  

Algunas técnicas

Right – BICEP• Right• Boundary• Inverse Relationships• Cross­check• Error condition• Performance

  

Boundary

CORRECT Conformance Ordering Range Reference Existence Cardinality Time

  

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.

  

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?

  

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.

  

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

  

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

  

TDD

Dejemos a los que saben.