SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
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
8.
Las herramientas
★Introspección (OCUnit)
★Inyección de dependencias
๏Constructor
๏Propiedades
★Mocks y stubs
8
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