Your SlideShare is downloading. ×
TDD Code Retreat
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

TDD Code Retreat

563
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
563
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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