3. Aviso para navegantes
★Esto no es una clase, sino
una experiencia compartida.
★Si compartes, aprendemos
todos.
★Si algo no te gusta, ofrece
tus alternativas.
3
4. ¿TDD?
★Test Driven Development
★Es una forma de escribir
software
★Supone pensar primero en la
verificación del código y
luego en escribirlo
4
5. ¿Por qué TDD?
★Codigo que hace lo que
pensamos.
★Programar en piloto
automático.
★Progreso medible.
★Mucho más fácil abordar
cambios.
5
6. Secuencia de trabajo
★Siguiente funcionalidad
★Escribir la prueba
★Escribir el código más simple
que pasa la prueba
★Refactorizar
★Repetir hasta acabar cada
historia
6
7. Código más corto
1.Más fijado (hard coded)
2.Más cerca del principio del
método
3.Menos sangrado (indented)
4.Más corto
7
Texto
http://osherove.com/blog/2010/1/6/tdd-4-questions-that-
will-help-you-create-the-simplest-thing.html
9. Las reglas del juego
★Sólo probamos nuestro código
★Sólo un nivel cada vez
★Sólo los métodos públicos
★Sólo una cosa en cada prueba
★Las pruebas son
independientes unas de otras
(ni secuencia, ni estado)
9
10. Algunos trucos
★Usar sut = reutilizar pruebas
★Confirmar que no hay avisos o
errores
★Separar en clases
★Refactorizar las pruebas
cuando interese
10
11. Inconvenientes
★ Más lento y más trabajo en calidad
★ Diseño sin visión de conjunto
★ Reescribir pruebas al cambiar
requisitos
★ Se requieren otras pruebas además
★ Mismas carencias las pruebas que
el código (sistema que no puede
entenderse a sí mismo, W.E.Deming)
11
12. Ventajas
★ Menos interactuación y menos
tiempo depurando
★ Más facil adaptarse a los cambios
★ Documentación en código y menos
asunciones.
★ Cobertura prácticamente total
12
19. Modelo de trabajo
1.Leer el código
2.Pensar una prueba que
confirma cómo funciona
3.Escribirla y ver que la pasa
4.Refactorizar si procede.
5.Repetir
19
20. Código limpio
★Aprovechar para limpiar el
código
★Eliminar repetición y ganar
consistencia
★Sólo un nivel de abstracción
por método
20