Javier Castañeda
@jdandini
Unit Testing
¿Te ha pasado que...?
● Al reescribir código quieres asegurarte de que todo funciona
● No estas seguro si tu arquitectura es correcta
● Quieres que tu código sea bug free
¿Te ha pasado que...?
● Heredas código y al hacerle cambios ruegas a todos los dioses
paganos para que algo no se rompa
¿Para qué hacemos pruebas automáticas?
● Probar que el código funcione
● Prevenir bugs y errores de regresión
● Ayuda a pensar sobre interacciones en tu código
● Escribir documentación viviente
Creas código mantenible
¿Qué debo probar?
1. Lo nuevo
2. La funcionalidad central
3. Flujos de UI más comunes
4. Límites
¿Cómo es una buena prueba?
● Rápida
● Aislada
● Repetible
● Auto validada
¿Qué herramienta uso para hacer pruebas?
El proceso
Verifica tu arquitectura
● ¿Las responsabilidades de las clases y métodos en tu aplicación
están bien definidas?
● Elimina acoplamiento de código
“Si no puedes probar algo fácilmente, tienes un
error en tu arquitectura”
Uncle Bob
Red, green & refactor
● Escribe una prueba
● Provoca un fallo a la prueba (inputs)
● Provoca que la prueba pase (inputs)
● Refactoriza tu prueba
Ventajas y desventajas
● Seguridad de que todo funciona
● Identificación de errores de regresión
● Seguridad al ejecutar cambios
● Mejor calidad de código
● Sólo se escriben una vez
Desventajas
● Mayor tiempo al desarrollar algo
● En caso de no tener es muy largo escribir pruebas
● Proceso “tedioso y aburrido”
¿Cómo creo una?
Demo
“QA no debe encontrar nada, ellos no son tu
detector de errores”
Uncle Bob
Fin
¿Preguntas?

Unit Testing en iOS

  • 1.
  • 2.
    ¿Te ha pasadoque...? ● Al reescribir código quieres asegurarte de que todo funciona ● No estas seguro si tu arquitectura es correcta ● Quieres que tu código sea bug free
  • 3.
    ¿Te ha pasadoque...? ● Heredas código y al hacerle cambios ruegas a todos los dioses paganos para que algo no se rompa
  • 4.
    ¿Para qué hacemospruebas automáticas? ● Probar que el código funcione ● Prevenir bugs y errores de regresión ● Ayuda a pensar sobre interacciones en tu código ● Escribir documentación viviente Creas código mantenible
  • 5.
    ¿Qué debo probar? 1.Lo nuevo 2. La funcionalidad central 3. Flujos de UI más comunes 4. Límites
  • 6.
    ¿Cómo es unabuena prueba? ● Rápida ● Aislada ● Repetible ● Auto validada
  • 7.
    ¿Qué herramienta usopara hacer pruebas?
  • 8.
  • 9.
    Verifica tu arquitectura ●¿Las responsabilidades de las clases y métodos en tu aplicación están bien definidas? ● Elimina acoplamiento de código
  • 10.
    “Si no puedesprobar algo fácilmente, tienes un error en tu arquitectura” Uncle Bob
  • 11.
    Red, green &refactor ● Escribe una prueba ● Provoca un fallo a la prueba (inputs) ● Provoca que la prueba pase (inputs) ● Refactoriza tu prueba
  • 12.
    Ventajas y desventajas ●Seguridad de que todo funciona ● Identificación de errores de regresión ● Seguridad al ejecutar cambios ● Mejor calidad de código ● Sólo se escriben una vez
  • 13.
    Desventajas ● Mayor tiempoal desarrollar algo ● En caso de no tener es muy largo escribir pruebas ● Proceso “tedioso y aburrido”
  • 14.
  • 15.
    “QA no debeencontrar nada, ellos no son tu detector de errores” Uncle Bob
  • 16.