1. Testing: la etapa olvidada

2. >>> from iferminm import info
>>> print info
{
'nombre': 'Israel Fermín Montilla',
'ocupación': 'Programador',
'egresado_de': 'UCAB',
'qué_hace_ahora': 'Lead Developer @ RingTu'
'twitter': '@iferminm',
'blog': 'http://iferminmontilla.com/'
}

3. Estamos contratando
empleo@ringtu.com
CV + Cover Letter

4. ¿Qué es programar?

5. Código

6. Ortogonalidad
(software orthogonality)

10. Brevísima historia del Testing
● Orientado al debugging (hasta 1956)
– Escribe, luego revisa
● Orientado a la demostración (1957-1978)
– Mostrar que cumple el objetivo
● Orientado a la destrucción (1979-1982)
– Mostrar que hay errores
● Orientado a la evaluación (1983-1988)
– Metodología, nace la ingeniería de pruebas
● Orientado a la prevención (1989-actualmente)

11. Orientado a la prevención
● Planificación de casos de prueba
● Distintos tipos de pruebas
● Cíclico... nunca termina
– … o al menos tarda en terminar
● El objetivo es producir software efectivo, no
software que sólo pase pruebas.

12. Debes programar como si quien va
a mantener tu código...
...es un pran de El Rodeo

14. Desarrollo guiado por pruebas
(Test Driven Development)

15. TDD

16. Beneficios
● Definición del requerimiento
● Obliga a escribir las pruebas
– Importante...
● Ayuda a definir el algoritmo
● Visualizar casos no previstos

17. Pruebas Unitarias
● ¿Qué son?
– Units: bloque específico del programa
– Test: prueba automatizada
● Entradas conocidas, salidas esperadas
Función suma
2
3
5

18. Pruebas Unitarias
● ¿Qué son?
– Units: bloque específico del programa
– Test: prueba automatizada
● Entradas conocidas, salidas esperadas
Función suma
2
3
5
Revisamos que la salida
Sea el valor esperado
Prueba unitaria

19. En un programa del mundo real

20. Problemas
● Data Inicial (fixtures)
– JSON, XML, YAML...
● Acceso a datos
– Escribir y leer de disco cuesta...
● Servicios externos
– Pueden hacer fallar la prueba...

21. Soluciones
● Sobre los fixtures
– Usar fábricas
● Acceso a datos
– Utilizar almacenamiento in-
memory
● Servicios externos
– Utilizar mockers

22. El argumento épico
● Las pruebas unitarias consumen tiempo, es
mejor lanzar nuevos features rápido, si da
tiempo las hacemos...

23. El argumento épico
● Las pruebas unitarias consumen tiempo, es
mejor lanzar nuevos features rápido, si da
tiempo las hacemos...

24. La respuesta coherente
● Es mejor invertir unas horas extra haciendo
pruebas que gastar semanas haciendo debug
de todo el programa para encontrar el código
que produce un error.

25. La respuesta coherente
● Es mejor invertir unas horas extra haciendo
pruebas que gastar semanas haciendo debug
de todo el programa para encontrar el código
que produce un error.

26. Ahora, manos al teclado

27. ¿Qué utilizaremos?