Experiencias y ejemplos sobre la automatización de pruebas de interfaces de usuario, incluyendo una introducción a BDD.

1. Pruebas de interfaz
automatizadas
e introducción a BDD
Santiago Rodríguez Sordo
@santiagorodsor

2. introducción a BDD

3. YAG
NI
1/234

4. Aproximación
cumplir las especificaciones
lenguaje coloquial
evalúan el código continuamente con
las especificaciones
2/234

5. BDD
Proceso de desarrollo de software
Specification by Example.
Son casos reales
3/234

6. BDD
¿¿¿ 3/234 ???

7. BDD
Requisitos y
comportamientos
Historia de usuario
Criterio de
aceptación

8. BDD, ¿qué requisitos?
Historia de usuario Criterio de aceptación
Escenario

9. BDD, ¿cómo los expreso?
Escenario: Veré mi nombre al entrar en la app.
Como usuario
Quiero entrar en la aplicación
De manera que vea mi nombre

10. BDD, ¿cómo los expreso?
Escenario: <Descripción de la historia>
Como <rol>
Quiero <acción>
De manera que <suceda algo>

11. BDD, ¿cómo los expreso?
Escenario: Un usuario ve todos los mensajes nuevos
Cómo usuario de la aplicación llego a la pantalla de notificaciones
Dado que veo que tengo 3 notificaciones de mensaje.
Cuando entro en la página de mensajes.
Observo que hay 3 mensajes nuevos.
Dado que entro en cada uno de ellos.
Entonces veo que no tengo ningún mensaje.

12. BDD, ¿cómo los expreso?
Gherkin

13. Gherkin
Feature
Background:
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too

14. Cheatsheet
Given (“dado”), llevará al sistema a un estado conocido
When (“cuando”), describe la acción clave
Then (“entonces”), describe salidas observables
And (“ y ”)
But (“ pero “)
https://github.com/cucumber/cucumber/wiki/Given-When-Then

15. Tus features
tu implementación guiar deben,
no esta reflejar.

16. ¿funcionará?

17. Proceso
1. Se elige un escenario.
2. Se implementa el código
3. ¿Pasa la prueba?
No -> Vuelve al paso 2
4. Cuando pase el test se da por bueno.
5. Escenario Done!

18. Evolutivo
1. Se hace una modificación.
2. Se pasa un test: ERROR
A: Si escenario correcto, he metido un bug.
B: Si la prueba no se ajusta al código, modifico la prueba y
vuelvo a evaluar.
C: Si la especificación a cambiado, desecho la prueba.

19. Todo el proceso
Historia de usuario feature
Feature 1
● Scenario1
● Scenario2
● Scenario3
Feature 2
● Scenario1
● Scenario2
● Scenario3
Feature 3
● Scenario1
● Scenario2
● Scenario3

20. … pero …
… son muchos escenarios ...
… utiliza la fuerza ...

21. Automatización de interfaz

22. Disponemos de máquinas,
que hagan el trabajo repetitivo.
La fuerz… AUTOMATIZACIÓN

23. La solución única no existe
Scenario:
As a Mobile Developer BDD-lover quiero adelantar trabajo.
Given no hay manera buena de desarrollar para Android e iOS a la vez.
When busco una prueba única Android e iOS
Then encuentro una manera buena de automatizar Android e iOS a la vez. FAIL
PASS
PASS
:(
:(

24. AUTOMATIZACIÓN
Nativo
Instruments - UIAutomation ”.js”
UIAutomator (Android) “.java”
Appium - Webdriver (iOS, Android).js, ( lento :( y poco fiable)

25. Apply: Appium http://appium.io/
PROs:
- Utiliza las herramientas nativas de cada plataforma.
- La interfaz es común (Android e iOS)
CONTRAs:
- Lento.
- Poco fiable.
- No tiene waits bien soportados.

26. AUTOMATIZACIÓN
iOS
Cedar http://pivotallabs.com/test-driven-iphone-development-with-cedar/
Kiwi
KIF

27. AUTOMATIZACIÓN
Cucumber
Calabash
Frank
iCuke

28. Apply: Calabash http://calaba.sh/
PROs:
- tiene muchos gestos soportados
- utiliza una interfaz “común” para iOS y Android.
- hay referencias de que se usa
CONTRAs:
- intrusivo en iOS Projects
- utiliza comandos de muy bajo nivel para muchas cosas

29. Apply: iCuke https://github.com/unboxed/icuke
PROs:
- acceso directo al runtime de la app vía HTTP
- acciones inside iOS APIS
- podría integrarse con calabash o cucumber
CONTRAs:
- parece anticuado (2010)
- demasiado incompleto

30. Apply: Frank http://www.testingwithfrank.com/
PROs:
- fácil de cargar entorno
- “buena” experiencia simulator/idevice
- no “intrusivo” en iOS projects
- symbiote
CONTRAs:
- mejorables gestos
- utiliza comandos de muy bajo nivel para muchas cosas

31. ¿Cómo lo hacen?

32. Cucumber
features/myfeature.feature
features/steps/myfeature_step.rb

33. Cucumber

34. Cucumber

35. Step by step

36. Step by step

37. Make your own steps

38. 1. gem server
2. browser, localhost:8808
3. frank-cucumber
4.
Make your own steps

39. selector + comando + parámetro
- (Array) frankly_map(selector, method_name, *method_args)
Ask Frank to execute an arbitrary Objective-C method on each
view which matches the specified selector.

40. Cucumber Wrap Up
Gherkin Steps
Frank
Calabash
iCuke

42. Si no lo veo no lo creo

43. Ya lo veo claro ...
Probaré ...

44. Ya lo veo claro ...
Probaré ...

45. Ya lo veo claro ...
Probaré ...

46. Ya lo veo claro ...
Probaré ...
Hasta el infinitoooo ...

48. No perdamos la especificación
Aplíquese:
- no sólo como automatización
- no en todas las combinaciones
- con criterio
- en el desarrollo
- sin pensar que va a hacerte el código. ^_^

49. Entonces... ¡ Cucumber es BDD!
NO !!!!

50. Se usa Cucumber para BDD
En BDD se tienen las pruebas alineadas con los
requerimientos.
Para ayudarnos usamos Cucumber.

51. Some tricks

52. Cuidado, pruebas automatizadas
El desarrollo cambia a menudo los puntos en los
que se apoyan,
hay que fijarlos en el desarrollo
y todo el equipo debe responsabilizarse.

53. Punto de apoyo = identificador
UIAccessibilityIdentification
“protocol used to associate a unique identifier with
elements in your user interface”
@property(nonatomic, copy) NSString *accessibilityIdentifier

54. Page Object Pattern

55. Page Object Pattern

56. Page Object Pattern

57. Page Object Pattern

58. Queries

59. Queries

60. Queries

61. Queries

62. wait

63. wait

64. wait

65. services

66. services

67. Wrap up:

71. http://www.testingwithfrank.com/
http://cukes.info/
https://cucumber.pro/
@santiagorodsor