t.d.d. testing: do it or die
DESCRIPTION
T.D.D. Testing: Do it or Die. ¿De qué estamos hablando?. T.D.D = 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) - PowerPoint PPT PresentationTRANSCRIPT
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
T.D.D.T.D.D.Testing: Do it or DieTesting: Do it or Die
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
¿De qué estamos hablando?¿De qué estamos hablando?
• T.D.D = 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)
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
El “Efecto Brócoli”El “Efecto Brócoli”
Todos sabemos que es bueno, pero nadie quiere comerlo
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
¿Por qué no?¿Por qué 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!”
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
¿Por qué no?¿Por qué no?
• “Programar pruebas lleva demasiado tiempo” y “Correr las pruebas lleva demasiado tiempo”
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
¿Por qué sí?¿Por qué sí?
• Se escriben pruebas (si es una opción, nadie las hace)
• Satisfacción personal: Se busca el sentimiento de logro. “La Programación en un esfuerzo humano)
• Aclaración de Interfaces y Comportamiento: Se dice qué se espera de cada clase ANTES de implementarla
• Verificación demostrable: Se provee de una fuente significativa de verificaciones de corrección
• Confianza en cambiar las cosas
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
¿Qué tengo que probar?¿Qué tengo que probar?
• El método RIGHT-BICEP– Right– Boundary– Inverse Relationships– Cross-check– Error condition– Performance
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
BBICEPICEP
La mayoría de los errores se encuentran en los extremos del problema.
Probar: – Datos extremos e incorrectos– Cadenas mal formadas(info@fdv.)– Valores vacíos en arrays. Ej: (1,1,,0)– Valores irracionales. Ej: edad de una persona
= 10000 años– Elementos duplicados– Ejecutar secuencias en órdenes inesperados.
Ej mandar a imprimir antes de guardar.
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
BBICICEPEP
• 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.
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
BICBICEPEP
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?
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
CORRECTCORRECT
– Conformance: ¿Respeta el formato?– Ordering: ¿Están los valores ordenados o
desordenados correctamente?– Range: ¿Es el rango correcto, hay valores
fuera del rango?– Reference: ¿Hace mi código referencia a
elementos externos que no manejo?– Existence: ¿Existe el valor?– Cardinality: ¿Hay exactamente la misma
cantidad de valores?– Time: ¿Ocurren las cosas en el orden temporal
que corresponde?
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
Una Ayuda: MockUna Ayuda: 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.
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
Mock: ¿Cuándo?Mock: ¿Cuándo?
• 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
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
Ciclo de VidaCiclo de Vida
• 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
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
Unit TestingUnit Testing
• Se busca probar cada unidad de código• Una unidad es la mínima parte
distinguible de un sistema: en OOP = método
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
JUnitJUnit
• Framework open-source que nos ayuda a generar las pruebas unitarias
• Permite standarizar los tests y correrlos en forma conjunta
• Ayuda a ver de manera amigable dónde y por qué falla una prueba
• Junit + IDE = Facilidad de Implementación• Los tests se agrupan en TestCases, que
pueden integrar TestSuites
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
JUnitJUnit
• Herramienta principal: ASSERT– assertTrue(expresion)– assertFalse(expresion)– assertEquals(esperado, real)– assertNotSame(objeto, objeto)– assertNull(objeto)– assertNotNull(objeto)
• Otras herramientas– setUp(): Realizar algo antes de cada test– tearDown(): Realizar algo después de cada test– fail(): Si se llega a esa parte del código, está mal
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
JUnitJUnit
• Mini-Ejemplo
75.0
7 –
Alg
ori
tmo
s y
Pro
gra
mac
ión
III
– T
est
Dri
ven
T
est
Dri
ven
D
evel
op
men
tD
evel
op
men
t
BibliografíaBibliografía
• Pragmatic Unit TestingHunt y Thomas.Pragmatic Programmers
• Thinking in Java (4ta Edition). Hasta la tercera esta disponible en forma gratuita
Eckel.Prentice Hall.
• Documentación JUnithttp://junit.org/