Slides utilizadas en charla a alumnos de Ingeniería del Software en la Escuela Politécnica de Gijón sobre:
- Necesidad de testing
- Problemas dentro de un proyecto
- Automatización de pruebas con Seleniun
Esta es la presentación que he preparado para mis compañeros de @NITSNETS en la que explico la integración del testing a todos los niveles de un proyecto y profundizo un poco más en la aplicación práctica para un entorno basado en Laravel.
Paso a paso explico como estructurar nuestros proyectos para ir solucionando y separando problemas para ver finalmente como la foto general de lo que hemos montado coincide con los principios de Clean Architecture y como esto nos ayuda a construir un software más solido, extensible y refactorizable.
Test driven development: advantages and common errors.
Why is important to use TDD?
What kind of things TDD give us?
Which are common errors using TDD?
With or without TDD?
Slides utilizadas en charla a alumnos de Ingeniería del Software en la Escuela Politécnica de Gijón sobre:
- Necesidad de testing
- Problemas dentro de un proyecto
- Automatización de pruebas con Seleniun
Esta es la presentación que he preparado para mis compañeros de @NITSNETS en la que explico la integración del testing a todos los niveles de un proyecto y profundizo un poco más en la aplicación práctica para un entorno basado en Laravel.
Paso a paso explico como estructurar nuestros proyectos para ir solucionando y separando problemas para ver finalmente como la foto general de lo que hemos montado coincide con los principios de Clean Architecture y como esto nos ayuda a construir un software más solido, extensible y refactorizable.
Test driven development: advantages and common errors.
Why is important to use TDD?
What kind of things TDD give us?
Which are common errors using TDD?
With or without TDD?
Cypress es un nuevo jugador en las herramientas de código abierto para pruebas automatizadas de software.
Presentado por Gilberto Sánchez en SG Virtual Conference 2020
Preview de los slides para el curso "Automate Testing"
Los slides completos del curso "Automate Testing" para .NET se encuentran en
http://www.slideshare.net/snahider/automate-testing-net
Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software developers and business analysts with shared tools and a shared process to collaborate on software development
Tras tres años programando en la plataforma Android esta es la película de mi vida como Android Developer, un conjunto de buenas practicas y conceptos necesarios que aún a día de hoy sigo viendo que no se cumplen en la mayoría de proyectos con los que me cruzo. Son la conclusiones sacadas de mi experiencia y de multitud de debates con compañeros. Se abordan temas como: fragmentación, uso de la clase Context, naming, maquetación en Android, memory leaks y S.O.L.I.D.
Esta separata se utiliza en el curso PROGRAMADOR JAVA que imparto en SistemasUNI.
Te recomiendo que visites:
http://gcoronelc.blogspot.pe/
http://gcoronelc.blogspot.pe/2016/10/eureka-cs-oracle-jdbc.html
http://www.desarrollasoftware.com/
Las pruebas son el único instrumento que puede determinar la calidad de un producto software, es decir, es el único método por el que se puede asegurar que un sistema software cumple con los requerimientos.
Cypress es un nuevo jugador en las herramientas de código abierto para pruebas automatizadas de software.
Presentado por Gilberto Sánchez en SG Virtual Conference 2020
Preview de los slides para el curso "Automate Testing"
Los slides completos del curso "Automate Testing" para .NET se encuentran en
http://www.slideshare.net/snahider/automate-testing-net
Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software developers and business analysts with shared tools and a shared process to collaborate on software development
Tras tres años programando en la plataforma Android esta es la película de mi vida como Android Developer, un conjunto de buenas practicas y conceptos necesarios que aún a día de hoy sigo viendo que no se cumplen en la mayoría de proyectos con los que me cruzo. Son la conclusiones sacadas de mi experiencia y de multitud de debates con compañeros. Se abordan temas como: fragmentación, uso de la clase Context, naming, maquetación en Android, memory leaks y S.O.L.I.D.
Esta separata se utiliza en el curso PROGRAMADOR JAVA que imparto en SistemasUNI.
Te recomiendo que visites:
http://gcoronelc.blogspot.pe/
http://gcoronelc.blogspot.pe/2016/10/eureka-cs-oracle-jdbc.html
http://www.desarrollasoftware.com/
Las pruebas son el único instrumento que puede determinar la calidad de un producto software, es decir, es el único método por el que se puede asegurar que un sistema software cumple con los requerimientos.
Selenium RC: Automated Testing of Modern Web Applicationsqooxdoo
This talk is concerned with automated testing of Web applications. It
looks at testing Web apps in general, its goals and challenges; it will
present Selenium and Selenium RC in particular as a testing platform;
and will then focus on adaptions made to Selenium to ease the effort
to test apps made with qooxdoo, a JavaScript framework.
SEMINARIO WEB EN VIVO: INTRODUCCIÓN AL AGILE TESTINGtbaires
En la actualidad, el concepto de Agilidad sigue evolucionando y con él las prácticas de desarrollo de software que adoptan como base un marco de trabajo ágil.
Durante el seminario se tratarán algunos conceptos básicos:
· ¿Por qué Testing Ágil?
· Los Principios Ágiles
· Esquema de Desarrollo Ágil
· Beneficios de las Prácticas Ágiles
· Los Valores del Testing Ágil
· Descripción del curso de Testing Ágil
Duración
1 hora
Fecha
27 de Julio de 2016
Horario
de 19 a 20 hs
Expositora:
Lic Miriam Alsogaray
https://ar.linkedin.com/in/miriam-alsogaray-2851348
Curso de test driven development usando AngularJS, Jasmine, Karma, Protractor, y Gulp para automatizar todo.
Codigo del proyecto de ejemplo:
https://github.com/rodrigopivi/angularComponentStarter
Slides de la Sesión #1 del Querétaro Software Development Meetup
Temas:
Entendiendo los beneficios de Unit Testing y TDD
Muchas veces confundido, tildado de ser una perdida de tiempo o simplemente no entender su potencial, Unit Testing o aspectos de desarrollo como Test Driven Development es algo que aún no se adapta en proyectos o incluso en prácticas a nivel compañia, sin embargo es una parte primordial del desarrollo de software. La finalidad de la plática teórica y práctica es dar una explicación (con PHP, PHPUnit y Mockery) de Unit Testing, sus beneficios y casos reales.
Simian Army: Fault-tolerance en el sistema, para adultos
Simian army es un set de herramientas desarrolladas por Netflix para verificar que sus servidores puedan recuperarse de errores, verificar que pasa caundo la red se alenta, etc. En esta plática teórica veremos cuales son los beneficios de tener un sistema asi en producción y entender la finalidad de la librería.
Diapositivas correspondientes a la parte sobre la plataforma de desarrollo Google App Engine del curso de extensión universitaria "Cloud Computing. Desarrollo de Aplicaciones y Minería Web", celebrado en la Escuela Universitaria de Ingeniería Informática de Oviedo
Charla Evento TestingUY 2016 - Automatización en Ruby 101TestingUy
Expositor: Rodrigo Gómez
Resumen: Veremos desde las características generales del lenguaje Ruby, a su uso para realizar pruebas funcionales. Distintas funciones útiles disponibles en bibliotecas del lenguaje para manejo de servicios, navegación y monitoreo; con ejemplos sencillos en cada caso.
Los emprendimientos socio productivos generan bienes y servicios en los territorios, con el propósito de que los procesos de producción activen al mercado y facilite el desarrollo personal mediante la integración social de los agentes sociales excluidos.
control de emisiones de gases contaminantes.pptxjesusbellido2
en el siguiente documento s epodra apreciar los gases que emiten los vehiculos y sus consecuencias tambien se podra apreciar las normas euro cino y las normas euro seis
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.
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
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
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
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)
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
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
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.
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.
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.
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.
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.