T.D.D. Testing: Do it or Die

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)‏ Sirve como método de documentación (no la reemplaza)‏

El “Efecto Brócoli” Todos sabemos que es bueno, pero nadie quiere comerlo

¿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!”

¿Por qué no? “Programar pruebas lleva demasiado tiempo” y “Correr las pruebas lleva demasiado tiempo”

¿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

¿Qué tengo que probar? El método RIGHT-BICEP Right Boundary Inverse Relationships Cross-check Error condition Performance

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

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

BICEP 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?

CORRECT • 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?

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

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

Ciclo 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

Unit Testing Se busca probar cada unidad de código Una unidad es la mínima parte distinguible de un sistema: en OOP = método

JUnit 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

JUnit 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

JUnit Mini-Ejemplo

Bibliografía Pragmatic Unit Testing Hunt y Thomas. Pragmatic Programmers Thinking in Java (4ta Edition). Hasta la tercera esta disponible en forma gratuita Eckel. Prentice Hall. Documentación JUnit http://junit.org/

T.D.D. Testing: Do it or Die