TDD Code Retreat

779 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
779
On SlideShare
0
From Embeds
0
Number of Embeds
47
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

TDD Code Retreat

  1. 1.    TDD  Agenda  TDD for Dummies  Porqué NO?.  Porqué SI?.  Algunas técnicas  Dejemos a los que saben!
  2. 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. 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. 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. 5.    Algunas técnicas  Right – BICEP • Right • Boundary • Inverse Relationships • Cross­check • Error condition • Performance
  6. 6.    Boundary  CORRECT  Conformance  Ordering  Range  Reference  Existence  Cardinality  Time
  7. 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. 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. 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. 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. 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. 12.    TDD Dejemos a los que saben.

×