Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

TDD

No description
by

Javier Gamarra Olmedo

on 9 June 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of TDD

TDD est riven evelopment Contexto Ventajas e inconvenientes Tips Recursos DISCLAIMER: Interrumpid con dudas!
¿enfoque de la presentación?
No soy un experto práctica de desarrollo software
basada en tests unitarios ¿? y refactorización ¿?
asociada a prácticas de XP ¿? y a calidad software
reinventada por Kent Beck (XP, JUnit, manifiesto ágil...) flujo:
red
green
refactor

repetir webs, podcasts, libros... miles
TDD by example de Kent Beck
Working Effectively with Legacy Code de Michael Feathers
Refactoring de Martin Fowler
Test-Driven de Koskela
TDD de Carlos Blé Ventajas: Inconvenientes Buzzword
No me garantiza que se vaya a aplicar refactor!
Hay que mantenerlos
¿Beneficios claros?
Doing the things right != doing the right things Assertions por concepto (3)
Dejar test en rojo (4) Elimina el 'miedo al cambio'
¿Test driven design?
Son una red de seguridad (regresión)
Documentan el código
Desarrollo rápido (no hay servidor...) TDD GOTCHI BABY STEPS (1) testear lo que se puede testear
(obvio¿?)(2)
son tests UNITARIOS
no se suele testear la interfaz Aplicabilidad ¿más? BDD + resto de tests + metodología + clean =
agile/software craftsman heaven
TDD as if you meant it
Ping-Pong TDD
Autotest Lanzo algunas preguntas:
¿qué código (UI...)?
¿cuanto code coverage?
¿obligatorio? Todos tenemos claro que los tests son buenos y...
... que si te planteas escribir los tests después, ya no les escribes guía el código final a base de :
constantes
solución final
triangulación 2 puntos clave:
Hacer tests bien (!)
Aplicar refactor extensamente (!) Hacer TDD bien es MUY difícil Los tests deben de ser:
rápidos (F)
independientes (I)
repetibles (R)
auto-validados (S)
a tiempo (T)
unitarios (sin BD...)
usarán mocks, stubs... Puntos de refactor:
DUPLICACIÓN
code smells
SOLID principles... TDD te obliga a pensar de antemano
que vas a probar, planteas un API ideal tamaño flexible TDD smells:
el test funciona directamente!
dos rojos seguidos, un paso muy grande ¿Escuela clásica o mockist? algunos resultados: http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

ejemplos: http://jamesshore.com/Blog/Lets-Play/
Full transcript