Workshop sobre cómo testear nuestras aplicaciones según la arquitectura definida. Testing adaptado a Clean Architecture. Testing en MO2O.

1. Testeando nuestras
aplicaciones
Chema
Android Developer

2. O2O DIGITAL BUSINESS
ÍNDICE
Introducción
Conceptos sobre testing
Inyección de Dependencias
Arquitectura Clean o Arquitectura por Capas
Testing en el módulo de Dominio
Testing en el módulo del Presentador
Testing en el módulo de Datos
Testing en el módulo de la Vista
Test de Integración
1
2
3
4
5
6
7
8
9

3. 1 O2O INTRODUCCIÓN
¿Otra charla de testing?
Experiencia en proyectos reales.
Unificar criterios para hacer testing.
Adaptada a nuestros proyectos: arquitectura, código, librerías,
etc.

4. 1 O2O INTRODUCCIÓN
¿Por qué hacer testing?
Ser profesionales en nuestro trabajo y responsables de lo que
hacemos.
Proyectos complicados de probar manualmente. Ej: estados
cronológicos.
Aporta calidad al producto.

5. 1 O2O INTRODUCCIÓN
Beneficios en nuestro código al hacer testing
Verifica que nuestro código hace lo que se espera de el.
Se reducen las incidencias de regresión.
Desarrollar sólo el código necesario para pasar el test.
Una guía para cumplir los principios SOLID.
Protocolo para poner en producción la aplicación.
Ayuda a estimar viendo los test afectados por el cambio.

6. 1 O2O INTRODUCCIÓN
Mitos sobre testing
Hacer tests implica un incremento de tiempo en el desarrollo
del código.
Hacer tests implica un código sin errores.
Los tests son responsabilidad de otros (QA).
Si el proyectó no comenzó desarrollandose con test, ya no
puedo meterlo en los evolutivos o correciones de incidencias.
Si no haces TDD no sirve de nada hacer test.

7. Conceptos sobre Testing2

8. 2 O2O CONCEPTOS
System Under Test (SUT) & Depend On Component (DOC)
SUT
DOC

9. O2O CONCEPTOS
Tipos de tests según su estructura
2
Caja Blanca
Entrada Salida
Caja Negra
Entrada Salida
Se centran en cómo se
trata las entradas para
producir las salidas
Se centran en las
entradas y salidas

10. O2O CONCEPTOS
Tipos de tests según su alcance
2
Test Unitarios Test de Integración Test de Aceptación
Presenter PresenterView Login

11. O2O CONCEPTOS
Técnicas de desarrollo de pruebas
2
Test Driven Development Test First Test Last
Relacionado con TDD. Puede no
refactorizarse.
1. Test.
2. Código para pasar test.
3. Refactorizar.
El programador realiza test
según el código escrito.

12. O2O CONCEPTOS
Dobles de Pruebas o Double Test
Pruebas Dobles o Double Test Un doble de test es simplemente un objeto que utilizamos en sustitución de otro cuando
queremos realizar un test y no queremos romper o ir más allá del SUT (Martín Fowler).
Dummy Es un tipo de doble de test y es un objeto que se usa para poder crear otros objetos. Se pasa como argumento y se
usan sólo para rellenar listas de parámetros.
Stubs Es un tipo de doble de test que devuelve datos predefinidos a una llamada hecha durante un test.
Fake Es un tipo de doble de test que funciona como si fuera real pero su implementación interna está adaptada a un entorno
de test y no de producción. Ej: base de datos en memoria.
Mock Objeto preprogramado que permite especificar qué se quiere recibir cuando se realiza una llamada determinada.
Spy Es como un mock pero además permite ir guardando las llamadas a los métodos que se van realizando.
2

13. O2O CONCEPTOS
Librerías
jUnit Es una librería que permite realizar la ejecución de clases Java de manera controlada, para poder evaluar si el
funcionamiento de cada uno de los métodos de la clase se comporta como se espera. Desarrollado por Erich Gamma y Kent
Beck.
Mockito Es una librería que permite la creación de test dobles (objetos). Permite verificar sus estados, llamadas a métodos,
etc.
Espresso Es un framework para realizar test en aplicaciones Android. Nos permite realizar pruebas sobre la interfaz de
usuario.
MockWebServer Es una librería que permite emular (fake) un servidor web. Gracias a esta librería podemos ver el
comportamiento de nuestra aplicación ante determinadas respuesta del servidor.
DaggerMock Es una librería que automatiza la creación de módulos (Dagger 2) para realizar test. Crea una regla jUnit y
sobreescribe los objetos creados con Dagger 2.
2

14. O2O CONCEPTOS
Librerías -
MockWebServer
2

15. Inyección de Dependencias3

16. 3 O2O INYECCIÓN DE DEPENDENCIAS
Conceptos

17. 3 O2O INYECCIÓN DE DEPENDENCIAS
Inversión de Control
Martín Fowler

18. 3 O2O INYECCIÓN DE DEPENDENCIAS
Principio de Inversión de Dependencias
El Caso de Uso depende de las clases instanciadas en el constructor.
Complicado saber de qué depende nuestro módulo. En métodos más difícil aún.
Complicado testear. Se dependen de esos módulos. Imposibilidad de reemplazar por test
dobles.
Robert C. Martin

19. 3 O2O INYECCIÓN DE DEPENDENCIAS
Principio de Inversión de Dependencias
Depende de una abstracción.
La relación con otros módulo se indica por constructor.
Posibilidad de hacer test dobles.
Robert C. Martin

20. 3 O2O INYECCIÓN DE DEPENDENCIAS
Inyección de Dependencias
Martín Fowler
Patrón de diseño.
Se suministran objetos a una clase en lugar de ser la propia clase quien cree el objeto
El Inyector de dependencias se encarga de sumistrar estos objetos
Dagger 2

21. Arquitectura Clean4

22. 4 O2O ARQUITECTURA CLEAN O ARQUITECTURA POR CAPAS
Definición de la
Arquitectura
Android
Java
Capa de Presentación
Views
Presenters
Capa de Dominio
Use Case
Models
Capa de Datos
Repository
Gateway
DataBase API

23. 4 O2O ARQUITECTURA CLEAN O ARQUITECTURA POR CAPAS
Módulos de la App
Módulo
Dominio
Módulo
Presentación
Módulo
App
Módulo
Datos
Módulo de App y Datos
Módulo de Presentación
Módulo de Dominio
Directo
Interfaz

24. 4 O2O ARQUITECTURA CLEAN O ARQUITECTURA POR CAPAS
Estructura del Proyecto en módulos
apply plugin: 'com.android.application'
apply plugin: ’java'
compile project(path: ':presentation')
compile project(path: ':domain')
compile project(path: ':data')
Módulo App Módulo Data
compile project(path: ':domain’)
Módulo Presentation
compile project(path: ':domain')
Módulo Dominio

25. Testing en el Módulo del
Dominio
5

26. 5 O2O TESTING EN EL MÓDULO DEL DOMINIO
Módulo del Dominio
Android
Java
Capa de Presentación
Views
Presenters
Capa de Dominio
Use Case
Models
Capa de Datos
Repository
Gateway
DataBase API

27. 5 O2O TESTING EN EL MODULO DEL DOMINIO
Contexto del problema
El caso de uso obtiene una receta.
Si la receta existe en local (base de datos) se devuelve.
Si la receta no existe en local, se obtiene desde una API.
Si la receta se ha obtenido desde la API, se persiste en local.
Si se produce un error al persistir, se ignora y se devuelve la receta.

28. 5 O2O TESTING EN EL MODULO DEL DOMINIO
Definición de Test Dobles

29. 5 O2O TESTING EN EL MODULO DEL DOMINIO
Contexto del problema
El caso de uso obtiene una receta.
Si la receta existe en local (base de datos) se devuelve.
Si la receta no existe en local, se obtiene desde una API.
Si la receta se ha obtenido desde la API, se persiste en local.
Si se produce un error al persistir, se ignora y se devuelve la receta.

30. 5 O2O TESTING EN EL MODULO DEL DOMINIO
Definición del Test

31. 5 O2O TESTING EN EL MODULO DEL DOMINIO
Contexto del problema
El caso de uso obtiene una receta.
Si la receta existe en local (base de datos) se devuelve.
Si la receta no existe en local, se obtiene desde una API.
Si la receta se ha obtenido desde la API, se persiste en local.
Si se produce un error al persistir, se ignora y se devuelve la receta.

32. 5 O2O TESTING EN EL MODULO DEL DOMINIO
Definición del Test

33. 5 O2O TESTING EN EL MODULO DEL DOMINIO
Contexto del problema
El caso de uso obtiene una receta.
Si la receta existe en local (base de datos) se devuelve.
Si la receta no existe en local, se obtiene desde una API.
Si la receta se ha obtenido desde la API, se persiste en local.
Si se produce un error al persistir, se ignora y se devuelve la receta.

34. 5 O2O TESTING EN EL MODULO DEL DOMINIO
Definición del Test

35. 5 O2O TESTING EN EL MODULO DEL DOMINIO
Contexto del problema
El caso de uso obtiene una receta.
Si la receta existe en local (base de datos) se devuelve.
Si la receta no existe en local, se obtiene desde una API.
Si la receta se ha obtenido desde la API, se persiste en local.
Si se produce un error al persistir, se ignora y se devuelve la receta.

36. 5 O2O TESTING EN EL MODULO DEL DOMINIO
Definición del Test

37. 5 O2O TESTING EN EL MODULO DEL DOMINIO
Resultado sin refactorizar

38. 5 O2O TESTING EN EL MODULO DEL DOMINIO
Resultado final (refactorización)

39. 5 O2O TESTING EN EL MODULO DEL DOMINIO
Resultado final (refactorización)

40. Testing en el Módulo del
Presenter
6

41. 6 O2O TESTING EN EL MÓDULO DEL PRESENTER
Modulo del Presenter
Android
Java
Capa de Presentación
Views
Presenters
Capa de Dominio
Use Case
Models
Capa de Datos
Repository
Gateway
DataBase API

42. 6 O2O TESTING EN EL MÓDULO DEL PRESENTER
El presentador se encarga de realizar una petición al dominio para obtener una receta y
manda a la vista que la muestre.
Para dar feedback al usuario de que la aplicación está realizando algo, se mostrará un
spinner.
El presentador será el encargado de indicarle a la vista que error deberá mostrar.
El presentador recoge los errores producidos al ejecutarse el caso de uso (desde el
dominio)
Contexto del problema

43. 6 O2O TESTING EN EL MÓDULO DEL PRESENTER
Definición de los Test
Dobles

44. 6 O2O TESTING EN EL MÓDULO DEL PRESENTER
Contexto del problema
El presentador se encarga de realizar una petición al dominio para obtener una receta y
manda a la vista que la muestre.
Para dar feedback al usuario de que la aplicación está realizando algo, se mostrará un
spinner.
El presentador será el encargado de indicarle a la vista que error deberá mostrar.
El presentador recoge los errores producidos al ejecutarse el caso de uso (desde el
dominio)

45. 6 O2O TESTING EN EL MÓDULO DEL PRESENTER
Definición del Test

46. 6 O2O TESTING EN EL MÓDULO DEL PRESENTER
Contexto del problema
El presentador se encarga de realizar una petición al dominio para obtener una receta y
manda a la vista que la muestre.
Para dar feedback al usuario de que la aplicación está realizando algo, se mostrará un
spinner.
El presentador será el encargado de indicarle a la vista que error deberá mostrar.
El presentador recoge los errores producidos al ejecutarse el caso de uso (desde el
dominio)

47. 6 O2O TESTING EN EL MÓDULO DEL PRESENTER
Definición del Test

48. 6 O2O TESTING EN EL MÓDULO DEL PRESENTER
Contexto del problema
El presentador se encarga de realizar una petición al dominio para obtener una receta y
manda a la vista que la muestre.
Para dar feedback al usuario de que la aplicación está realizando algo, se mostrará un
spinner.
El presentador será el encargado de indicarle a la vista que error deberá mostrar.
El presentador recoge los errores producidos al ejecutarse el caso de uso (desde el
dominio)

49. 6 O2O TESTING EN EL MÓDULO DEL PRESENTER
Definición del Test

50. Testing en el Módulo de Datos7

51. 7 O2O TESTING EN EL MÓDULO DE DATOS
Modulo de Datos
Android
Java
Capa de Presentación
Views
Presenters
Capa de Dominio
Use Case
Models
Capa de Datos
Repository
Gateway
DataBase API

52. 7 O2O TESTING EN EL MÓDULO DE DATOS
La clase Local debería devolver el valor que indica si es la primera vez o no que se lanza
la app.
La clase local debería persistir un valor que indica que no es la primera vez que se
ejectura.
Contexto del problema

53. 7 O2O TESTING EN EL MÓDULO DE DATOS
Definición de los Test
Dobles

54. 7 O2O TESTING EN EL MÓDULO DE DATOS
La clase Local debería devolver el valor que indica si es la primera vez o no que se lanza
la app.
La clase local debería persistir un valor que indica que no es la primera vez que se
ejectura.
Contexto del problema

55. 7 O2O TESTING EN EL MÓDULO DE DATOS
Definición del Test

56. 7 O2O TESTING EN EL MÓDULO DE DATOS
La clase Local debería devolver el valor que indica si es la primera vez o no que se lanza
la app.
La clase local debería persistir un valor que indica que no es la primera vez que se
ejectura.
Contexto del problema

57. 7 O2O TESTING EN EL MÓDULO DE DATOS
Definición del Test

58. Testing en la Vista8

59. 8 O2O TESTING EN EL MÓDULO DE LA VISTA
Modulo de la Vista
Android
Java
Capa de Presentación
Views
Presenters
Capa de Dominio
Use Case
Models
Capa de Datos
Repository
Gateway
DataBase API

60. 8 O2O TESTING EN EL MÓDULO DE LA VISTA
Contexto del problema
Siempre que se inicie la actividad, debemos asegurarnos que es la
única activa.
Su Layout definido es R.layout.activity_login.
Debería inicializarse el presentador con la interfaz de la vista.
Al inicializarse la vista, el Alias Input y Password Input debe estar
vacío y con unos hint establecidos.
Si el login es correcto, se cambia de actividad ReceiptActivity.

61. 8 O2O TESTING EN EL MÓDULO DE LA VISTA
Definición de los Test
Dobles

62. 8 O2O TESTING EN EL MÓDULO DE LA VISTA
Contexto del problema
Siempre que se inicie la actividad, debemos asegurarnos que es la
única activa.
Su Layout definido es R.layout.activity_login.
Debería inicializarse el presentador con la interfaz de la vista.
Al inicializarse la vista, el Alias Input y Password Input debe estar
vacío y con unos hint establecidos.
Si el login es correcto, se cambia de actividad ReceiptActivity.

63. 8 O2O TESTING EN EL MÓDULO DE LA VISTA
Definición del Test

64. 8 O2O TESTING EN EL MÓDULO DE LA VISTA
Contexto del problema
Siempre que se inicie la actividad, debemos asegurarnos que es la
única activa.
Su Layout definido es R.layout.activity_login.
Debería inicializarse el presentador con la interfaz de la vista.
Al inicializarse la vista, el Alias Input y Password Input debe estar
vacío y con unos hint establecidos.
Si el login es correcto, se cambia de actividad ReceiptActivity.

65. 8 O2O TESTING EN EL MÓDULO DE LA VISTA
Definición del Test

66. 8 O2O TESTING EN EL MÓDULO DE LA VISTA
Contexto del problema
Siempre que se inicie la actividad, debemos asegurarnos que es la
única activa.
Su Layout definido es R.layout.activity_login.
Debería inicializarse el presentador con la interfaz de la vista.
Al inicializarse la vista, el Alias Input y Password Input debe estar
vacío y con unos hint establecidos.
Si el login es correcto, se cambia de actividad ReceiptActivity.

67. 8 O2O TESTING EN EL MÓDULO DE LA VISTA
Definición del Test

68. 8 O2O TESTING EN EL MÓDULO DE LA VISTA
Contexto del problema
Siempre que se inicie la actividad, debemos asegurarnos que es la
única activa.
Su Layout definido es R.layout.activity_login.
Debería inicializarse el presentador con la interfaz de la vista.
Al inicializarse la vista, el Alias Input y Password Input debe estar
vacío y con unos hint establecidos.
Si el login es correcto, se cambia de actividad ReceiptActivity.

69. 8 O2O TESTING EN EL MÓDULO DE LA VISTA
Definición del Test

70. 8 O2O TESTING EN EL MÓDULO DE LA VISTA
Contexto del problema
Siempre que se inicie la actividad, debemos asegurarnos que es la
única activa.
Su Layout definido es R.layout.activity_login.
Debería inicializarse el presentador con la interfaz de la vista.
Al inicializarse la vista, el Alias Input y Password Input debe estar
vacío y con unos hint establecidos.
Si el login es correcto, se cambia de actividad ReceiptActivity.

71. 8 O2O TESTING EN EL MÓDULO DE LA VISTA
Definición del Test

72. 8 O2O TESTING EN EL MÓDULO DE LA VISTA
Otros contextos del problema
La actividad no debería tener Toolbar – ActionBar.
El EditText del password debería ser ‘tipo password’.
El botón del Login debería ser visible y desactivado al iniciar la actividad.
Los textos que deberían llevar los hint de Alias y Password y la etiqueta del botón
Login.
Número de páginas del ViewPager.
Imagen según la página del View Pager.
Ocultar/Mostrar Spinner o Notificaciones.

73. Test de Integración9

74. 9 O2O TEST DE INTEGRACIÓN
Test de Integración
Hacer Login. El usuario introduce un alias y un password y valida sus
credenciales pulsando en el botón de Aceptar:
Si al hacer login las credenciales son incorrectas, se muestra un error.
Si al hacer login las credenciales son correctas, se cambia de actividad.
Si se produce un TimeOut en el servidor, se debe mostrar un mensaje de error de
red.

75. 9 O2O TEST DE INTEGRACIÓN
PageObject (Martín Fowler)
Clase que contiene todas las acciones que se pueden hacer en la vista.
Beneficios en la reutilización de acciones entre actividades.

76. 9 O2O TEST DE INTEGRACIÓN
Definición del Test

77. 9 O2O TEST DE INTEGRACIÓN
Definición del Test

78. 9 O2O TEST DE INTEGRACIÓN
Definición del Test

79. 9 O2O TEST DE INTEGRACIÓN
Test de Integración
Hacer Login. El usuario introduce un alias y un password y valida sus
credenciales pulsando en el botón de Aceptar:
Si al hacer login las credenciales son incorrectas, se muestra un error.
Si al hacer login las credenciales son correctas, se cambia de actividad.
Si se produce un TimeOut en el servidor, se debe mostrar un mensaje de error de
red.

80. 9 O2O TEST DE INTEGRACIÓN
Definición del Test

81. 9 O2O TEST DE INTEGRACIÓN
Test de Integración
Hacer Login. El usuario introduce un alias y un password y valida sus
credenciales pulsando en el botón de Aceptar:
Si al hacer login las credenciales son incorrectas, se muestra un error.
Si al hacer login las credenciales son correctas, se cambia de actividad.
Si se produce un TimeOut en el servidor, se debe mostrar un mensaje de error de
red.

82. 9 O2O TEST DE INTEGRACIÓN
Definición del Test

83. 9 O2O TEST DE INTEGRACIÓN
Test de Integración
Hacer Login. El usuario introduce un alias y un password y valida sus
credenciales pulsando en el botón de Aceptar:
Si al hacer login las credenciales son incorrectas, se muestra un error.
Si al hacer login las credenciales son correctas, se cambia de actividad.
Si se produce un TimeOut en el servidor, se debe mostrar un mensaje de error de
red.

84. 9 O2O TEST DE INTEGRACIÓN
Definición del Test

85. Chema
Android Developer
___________________________________________________
MO2O
Avda. De Burgos 8 – Pl. 16 – Edif. Bronce . Madrid 28036
910 609 514 - 609 242 417