agile software development & services

Cómo escribir buenos test

al hacer TDD

www.10pines.com

Hernán Wilkinson

Twitter: @HernanWilkinson

Blog: objectmodels.blogspot.com

www.10pines.com

¿Qué es TDD?

Técnica de Aprendizaje

Iterativa e Incremental

Basada en Feedback Inmediato

Como side-effect:

Recuerda todo lo aprendido

Y permite asegurarnos de no haber “desaprendido”

Incluye análisis, diseño, programación y testing

¿Cómo se hace TDD?

1) Escribir un test

- Debe ser el más sencillo que se nos ocurra - Debe fallar al correrlo

¿Cómo se hace TDD?

1) Escribir un test

- Debe ser el más sencillo que se nos ocurra - Debe fallar al correrlo

2) Correr todos los tests

- Implementar la solución más simple que haga pasar el/los test/s

- GOTO 2 hasta que “todos los tests” pasen

¿Cómo se hace TDD?

1) Escribir un test

- Debe ser el más sencillo que se nos ocurra - Debe fallar al correrlo

2) Correr todos los tests

- Implementar la solución más simple que haga pasar el/los test/s

- GOTO 2 hasta que “todos los tests” pasen

3) Reflexiono - ¿Se puede mejorar el código?

- Sí -> Refactorizar. GOTO 2

- No -> GOTO 1

¿Cómo se hace TDD?

1) Escribir un test

- Debe ser el más sencillo que se nos ocurra - Debe fallar al correrlo

2) Correr todos los tests

- Implementar la solución más simple que haga pasar el/los test/s

- GOTO 2 hasta que “todos los tests” pasen

3) Reflexiono - ¿Se puede mejorar el código?

- Sí -> Refactorizar. GOTO 2

- No -> GOTO 1

¿Cómo se hace TDD?

1) Escribir un test

- Debe ser el más sencillo que se nos ocurra - Debe fallar al correrlo

2) Correr todos los tests

- Implementar la solución más simple que haga pasar el/los test/s

- GOTO 2 hasta que “todos los tests” pasen

3) Reflexiono - ¿Se puede mejorar el código?

- Sí -> Refactorizar. GOTO 2

- No -> GOTO 1

Regla 1: Si el test no falla la primera vez que corre es porque: a) Estamos testeando algo

testeado b) Nos adelantamos en el

paso 2

¿Cómo se hace TDD?

1) Escribir un test

- Debe ser el más sencillo que se nos ocurra - Debe fallar al correrlo

2) Correr todos los tests

- Implementar la solución más simple que haga pasar el/los test/s

- GOTO 2 hasta que “todos los tests” pasen

3) Reflexiono - ¿Se puede mejorar el código?

- Sí -> Refactorizar. GOTO 2

- No -> GOTO 1

¿Cómo se hace TDD?

1) Escribir un test

- Debe ser el más sencillo que se nos ocurra - Debe fallar al correrlo

2) Correr todos los tests

- Implementar la solución más simple que haga pasar el/los test/s

- GOTO 2 hasta que “todos los tests” pasen

3) Reflexiono - ¿Se puede mejorar el código?

- Sí -> Refactorizar. GOTO 2

- No -> GOTO 1

Regla 2: Sensar el tiempo que nos lleva

realizar cada paso

Tiempo

Si nos lleva mucho tiempo escribir el test

El test no es el más sencillo

¿Nos cuesta mucho crear los objetos para la prueba?

Hay que crear objetos que ayuden en la creación de objetos

El diseño del sistema no es bueno y nos dificulta la escritura del test

Tiempo

Si nos lleva mucho tiempo hacer pasar el test

El test no era el más sencillo Borrar el test e intentar con uno más sencillo

La implementación no resuelve el problema ¡Debuggear!

El diseño del sistema no es bueno y nos dificulta la implementación de nueva funcionalidad Hacer paso 3

para mejorar el diseño antes de seguir

Tiempo

Los test tardan mucho tiempo en ejecutar

El sistema está acoplado con recursos externos que hace que ejecute “lento”. Ejemplo: Base de datos

Los test no verifican funcionalidad sino performance

Test de performance se hacen con testing, no TDD

Tiempo

Tardo mucho en hacer refactorings

¡Aprender refactorings automatizados!

Si están programando con editores de texto ¡pasar a un IDE!

Aprender como hacer cambios chicos por medio de refactorings encadenados

El diseño del sistema es muy malo, esta muy acoplado y no queda otra que tomarse tiempo para arreglarlo

Estructura de los tests

Setup

Exercise

Assert

Establece el contexto inicial para la ejecución del test. Pre-condición del test (puede ser reificado en mensaje setUp)

Ejercita la funcionalidad específica que se está testeando. Determina QUÉ se está testeando.

Verifica que los resultados sean los esperados. Post-condición del test

Ejemplo

▶ Algoritmo para calcular los factores primos de un número entero. Debe devolver una lista con ellos

– 1 -> {} (no tiene factores primos)

– 2 -> { 2 }

– 3 -> { 3 }

– 4 -> { 2,2 }

– 5 -> { 5 }

– 6 -> { 2,3 }

– 7 -> { 7 }

– 8 -> { 2,2,2 }

– 9 -> { 3,3 }

– 10 -> { 2,5 }

– Etc

¿Cómo lo llamamos?

¿Qué tal así?

¿Entonces cómo llamamos este?

Regla 3: Nombrar los tests sintetizando el

setup, exercise y assertions en una frase

Tip: Nombrar los tests cuando hayamos avanzado en la solución

¿Cuál es el setup y exercise?

Setup

Exercise

Assert

¿Qué tal este?

No suena muy bien…

¿Cómo llamamos estos tests?

Nombres casi iguales… “Nombres repetidos” ¡Tests del mismo caso!

¡Mismo caso funcional!

Regla 4: Nombrar los tests en base al caso

funcional y no en base a los datos de prueba

Tip: Dato de Prueba != Caso de Prueba

Dato de Prueba: Ejemplos concretos que “definen” un caso de prueba

Caso de Prueba: Generalización que incluye los datos de prueba

¡Me da miedo! ¿Qué pasa si …?

Decisión complicada… Números primos infinitos… Ver la implementación

lamentablemente

Ejemplo

▶ Modelar un Calendario de días feriados al que se le pueda preguntar si una fecha es feriado o no

▶ Se pueda indicar qué días son feriados de la siguiente manera:

– Por medio de un día de la semana, ej. Domingo

– Por medio de un día de un mes, ej. 25 de Diciembre

– Por medio de un día particular, ej. 20/4/2012

¿Cómo lo llamamos?

¿Si hago un test con 3 días pasará?

¿y con 4 …? ¿y con 7?

¡Inducción Incorrecta!

Regla 5: ¡Los tests no son una verificación

formal! Técnica: Testar con datos testigos Técnica: Testar con datos bordes

¿Aserción luego del set up?

¿Aserción luego del set up?

Para pensar… first ?

Separar el test en 2

¿Exercise luego de aserción?

¿Exercise luego de aserción?

Para pensar… first ? second?

Separar el test en 2

Regla 6: Los tests deben seguir la

estructura setup-exercise-assertion

first ? second?

Pensar en “tipo” no en implementación

Regla 7: Las aserciones sobre colecciones no deben acoplar a la implementación

Regla 8: Las aserciones

sobre colecciones deben asegurar la doble inclusión

Tip: asertar size e inclusión de cada objeto

Aserción repetida Aserción repetida

¡Reificar aserciones!

Regla 9: Los tests son un sistema más que

hay que desarrollar y mantener. Hacerlo usando las mismas

reglas de diseño que el sistema principal

Regla 10: Los tests son un sistema que usa el sistema principal, por lo tanto los

tests nos convierten en los primeros usuarios del sistema principal y nos

hacen sufrir sus problemas

¿Va a funcionar siempre?

¿Qué problema de diseño tiene esta implementación?

¡Saco acoplamiento

parametrizando la fecha!

¡Ahora la fecha de prueba es relativa, no absoluta!

¡Ahora va a funcionar siempre, no importa que día sea hoy!

Regla 11: Cuando hay dependencia entre datos de prueba e implementación,

romper el acoplamiento parametrizando

Tip: siempre usar datos de prueba relativos, no absolutos

Regla 12: Nunca acoplar la implementación con fuentes de información ni sistemas

externos, parametrizar

Acceso via interface REST El carrito pasa a ser

inválido (inutilizable) luego de 30 minutos de no usarlo

¿Qué principio de diseño se está violando? ¿Cómo lo evito? ¿Qué

tiene que controlar el test?

Reloj manual para controlar el paso del tiempo

Parametrizo cómo obtiene la hora

Reloj manual para controlar el paso del tiempo

Parametrizo cómo obtiene la hora

Reloj manual para controlar el paso del tiempo

Simulo paso del tiempo

Regla 13: El test tiene que estar en control de

TODO (hasta del paso del tiempo si es

necesario)

Tip: Si hay que controlar el tiempo, simular el reloj

¿Cómo hay que testear excepciones?

Solo la colaboración que levanta la excepción

Solo la colaboración que levanta la excepción

Aserto que se levantó la ex. esperada

Solo la colaboración que levanta la excepción

Aserto que se levantó la ex. esperada

Aserto sobre la post-condición

Regla 14: Cuando se testea por excepciones

se debe: 1) Una colaboración en el try 2) Asertar exc. correcta 3) Asertar post-condición Tip: falta de aserción sobre post-condición puede indicar que no estamos modelando

algo

Referencia directa a la base de datos

Referencia directa a la base de datos y cómo se busca en ella

¿Cómo rompo este acoplamiento?

Modela un sub-sistema

Lo implementa de manera persistente

Lo implementa de manera transient

Regla 15: Modelar los conjuntos de objetos

(sistemas)

Tip: Queda representada la arquitectura del sistema por medio de objetos

¿Cómo defino que subsistema usar?

Regla 16: Modelar los ambientes de

ejecución y dejarlos como único punto de

acceso a toda la información

▶ Regla 1: Si el test no falla la primera vez es porque …

▶ Regla 2: Sensar el tiempo que nos lleva realizar cada paso

▶ Regla 3: Nombrar los tests sintetizando el setup, exercise y assertions en una frase

▶ Regla 4: Nombrar los tests en base al caso funcional y no en base a los datos de prueba

Conclusiones

▶ Regla 5: ¡Los tests no son una verificación formal!

▶ Regla 6: Los tests deben seguir la estructura setup-exercise-assertion

▶ Regla 7: Las aserciones sobre colecciones no deben acoplar a la implementación

▶ Regla 8: Las aserciones sobre colecciones deben asegurar la doble inclusión

Conclusiones

▶ Regla 9: Los tests son un sistema más que hay que desarrollar y mantener …

▶ Regla 10: … los tests nos convierten en los primeros usuarios del sistema …

▶ Regla 11: … romper el acoplamiento parametrizando

▶ Regla 12: Nunca acoplar la implementación con fuentes de información ni sistemas externos, parametrizar

Conclusiones

▶ Regla 13: El test tiene que estar en control de TODO

▶ Regla 14: Cuando se testea por excepciones se debe …

▶ Regla 15: Modelar los conjuntos de objetos (sistemas)

▶ Regla 16: Modelar los ambientes de ejecución y dejarlos como único punto de acceso a toda la información

Conclusiones

agile software development & services

Muchas gracias!

info@10pines.com www.10Pines.com twitter: @10Pines

Argentina Tel.: +54 (11) 6091-3125 Av. Alem 693, 5B (1001) Buenos Aires