En este artículo, compararemos las capacidades de prueba de aplicaciones nativas y multiplataforma. Compartiré mis impresiones de trabajar con Flutter y les diré qué herramientas usamos en Surf cuando hacemos pruebas, por qué Flutter es conveniente y qué problemas encontramos.
Las capacidades de prueba en Flutter están a la par con las nativas
Cuando una empresa cambia su enfoque de desarrollo o surge una nueva tecnología, es importante que las capacidades de prueba no se vean gravemente afectadas. Idealmente, cuando se trabaja con un nuevo lenguaje o marco, los especialistas en control de calidad continúan utilizando la pila familiar de herramientas y tecnologías que han demostrado su eficacia de la mejor manera.
Cuando probamos aplicaciones nativas, en Surf usamos autotest y leemos y reemplazamos paquetes. En ningún lugar sin autotests, especialmente con regresión, y sin la ayuda de un proxy, la variabilidad de la aplicación y la cobertura de muchos casos disminuyen.
Para nosotros era importante que las funciones familiares permanecieran al probar las aplicaciones de Flutter.
Auto prueba
Surf funciona con los marcos Calabash y Ruby para realizar pruebas automáticas de aplicaciones nativas. Cuando apareció Flutter, lo primero que nos preguntamos fue: ¿es posible no usar Calabash, pero al mismo tiempo trabajar completamente con autotests de la forma en que estamos acostumbrados, o incluso mejor?
Resultó que no solo es posible, sino incluso sin servicios de terceros: en Flutter, las pruebas de integración y las pruebas de widgets en la consola están disponibles listas para usar. Nuestro desarrollador de Flutter habló sobre esto con más detalle en el artículo sobre pruebas automáticas en Flutter .
Las pruebas automáticas en Flutter son multiplataforma y nativas al mismo tiempo: puede escribir pruebas dentro del proyecto de la aplicación y funcionarán en ambas plataformas. Cuando todo el proyecto está frente a sus ojos, puede agregar id-schnicks faltantes o incluso encontrar errores y corregirlos; esta es otra oportunidad para mejorar la calidad de la aplicación.
Flutter también es compatible con el enfoque de desarrollo impulsado por el comportamiento - BDD. Lo usamos para pruebas de UI. Elegimos Gherkin como idioma: puede usar archivos de características en él, escribir scripts en inglés y ruso. Es comprensible, tiene la implementación de pasos de script sin argumentos adicionales dentro o con ellos, la capacidad de personalizar el lanzamiento de autotests: por ejemplo, ejecutar algunos scripts por etiquetas, y no todas las pruebas escritas en su conjunto.
Para usar Gherkin al probar aplicaciones de Flutter, conectamos el marco de código abierto flutter_gherkin .
Cuando nos dimos cuenta de que hay pruebas automáticas en Flutter, nos preguntamos cuáles son las diferencias entre las tecnologías Calabash y Dart + Gherkin, qué enfoque es mejor. Vamos a compararlos juntos.
1. Los archivos de características son absolutamente idénticos para ambos enfoques.
Por ejemplo, el script para la autorización por código pin se interpretará correctamente tanto en Dart como en Ruby usando Calabash:
: ( )
Ambas tecnologías admiten ruso, inglés y otros idiomas.
2. Los pasos son diferentes en la implementación.
| Dardo + flutter_gherkin
|
Calabaza
|
|
|
3. Flutter usa un archivo .dart adicional para configurar y trabajar con pruebas. Con Calabash, no existe tal archivo único.
En nuestra opinión, es imposible decir que esto es un revuelo dentro de Flutter o Calabash; esto es solo lo específico de trabajar con herramientas y tecnologías específicas.
4.Para la conveniencia de trabajar con elementos en la aplicación, es necesario que cada elemento tenga su propia identificación. Cuando trabaje con autotests con Calabash, debe tener cuidado de antemano de que ambas plataformas tengan id en las aplicaciones probadas. En Dart, puede agregar una identificación en el proceso de escribir pruebas automáticas, sin volver a cargar los archivos de las aplicaciones de iOS y Android por separado; esto es conveniente y ahorra tiempo.
Nuestra conclusión: las pruebas automáticas en Dart no son inferiores a las pruebas automáticas que utilizan el marco de trabajo de Calabash.
Proxies
Para aumentar la cobertura de aplicaciones por casos, Surf utiliza programas para leer y falsificar el tráfico, como Charles. El análisis de la interacción cliente-servidor permite:
- Determine si existe una interacción real con el backend.
- Descubra de qué lado está el problema: en el cliente o en el servidor.
- , .
- : , , . Charles , , , .
Dart tiene su propio cliente para trabajar con la red. Dado que todas las solicitudes pasan por él, la configuración necesaria para trabajar con un proxy debe ingresarse dentro de la aplicación. Para comodidad de los probadores, todos los ajustes necesarios se colocan en una pantalla separada: en Surf usamos la pantalla de depuración, que desarrollamos nosotros mismos.
La pantalla de depuración es una pantalla de configuración adicional que solo está disponible desde la compilación de depuración y ayuda con las pruebas. En él, puede seleccionar el servidor requerido, habilitar el uso de leer y guardar solicitudes http en la aplicación, ver el token fcm del dispositivo y más; hay muchas oportunidades para realizar pruebas.
La pantalla de depuración es personalizada: los desarrolladores le agregan elementos adicionales a petición de los probadores, por ejemplo, campos para configurar proxies desde la aplicación. Por lo tanto, tenemos todas las oportunidades para trabajar con Charles: puede conectar un servidor proxy a Debug Screen sin reiniciar la aplicación.
Como puede ver, las posibilidades de probar aplicaciones de Flutter no están limitadas. Todo lo que estamos acostumbrados a trabajar cuando es nativo es conveniente y fácil de usar. Estas son buenas noticias.
Problemas: errores de marco, fallas en bibliotecas de terceros, comportamiento nativo esperado
Los problemas a los que nos enfrentamos al probar las aplicaciones de Flutter también son nativos. No se puede decir que estas sean las deficiencias específicas de Flutter: en cualquier tecnología, la resolución de problemas no siempre es obvia y simple.
Te diremos qué buscar al probar aplicaciones de Flutter. Prevenido vale por dos.
Errores de Flutter-framework
Durante las pruebas, encontramos un problema con la visualización y el formato de fuentes en iOS: el espacio entre letras en la plataforma iOS era notablemente más ancho que en Android. Esto provocó muchos errores visuales.
Resultó que el problema estaba en el propio marco. Cuando nuestros desarrolladores de aplicaciones móviles pidieron a los chicos de la comunidad de desarrolladores de framework Flutter que corrigieran un error tan desagradable, el framework se actualizó pronto y la visualización de texto en iOS se corrigió.
Seguramente este tipo de situaciones se repetirán. Pero esto no se puede llamar un gran problema: los chicos de la comunidad de Flutter responden rápidamente a los problemas, apoyan y desarrollan el marco.
Deficiencias en bibliotecas de terceros
En las versiones 10 y 11 de iOS, se encontraron fallas de implementación en bibliotecas de terceros. Por ejemplo, estábamos arreglando un error cuando el permiso para acceder a las notificaciones aparece inmediatamente cuando se inicia la aplicación, y no en el botón, como estaba previsto por la especificación técnica y el diseño.
Estos problemas pueden ocurrir tanto en la plataforma cruzada como en la nativa. Se resuelven mediante arreglos dentro del proyecto o junto con los desarrolladores de la biblioteca.
Manejo del comportamiento nativo esperado
Con el uso a largo plazo y las pruebas de aplicaciones nativas en iOS y Android, es fácil predecir las expectativas del usuario a partir del comportamiento de diferentes aplicaciones. Entonces, por ejemplo, volver con un backwipe en iOS es un gesto estándar. Y en Android, no lo necesitas.
Los cuadros de diálogo del sistema en ambas plataformas son diferentes: en iOS, debe solicitar permiso para acceder a las notificaciones, y en Android, este acceso se proporciona de forma predeterminada.
Son estas partes de las especificaciones del sistema operativo las que a menudo deben terminarse manualmente. Y a veces, para cortar, si de repente el comportamiento esperado para la plataforma iOS migró a Android, como fue el caso con backwipe.
En las aplicaciones nativas, problemas como la actualización de la pantalla, la minimización incorrecta de la aplicación y el funcionamiento de una aplicación inusual para el sistema operativo actual son raros: las herramientas y tecnologías para desarrollar una aplicación para una plataforma específica obviamente tienen como objetivo cubrir todas las versiones y capacidades de un sistema específico.
Al probar una de las aplicaciones de Flutter, nos enfrentamos a una situación interesante: la capacidad de actualizar la pantalla no estaba disponible en dispositivos iOS con flequillo, comenzando con el iPhoneX y versiones posteriores. Al mismo tiempo, los dispositivos iOS sin flequillo y Android funcionaban correctamente.
Encontramos otro error en la versión 6 de Android: cuando se minimiza, la aplicación se descarga completamente de la memoria.
Estos errores fueron corregidos por nuestros desarrolladores dentro del proyecto.
iOS es muy consciente de sus dispositivos y sistemas, qué chips lanzan con la nueva versión del sistema operativo y cuáles ya no funcionarán en versiones anteriores, en qué enfocarse al actualizar el mismo Swift. Android entiende que tienen que apuntar a una gran cantidad de dispositivos y tamaños de pantalla completamente diferentes, y también conocen sus detalles.
Me gustaría que la multiplataforma contenga todas las sutilezas de la implementación del desarrollo nativo. Por supuesto, existen algunas deficiencias al trabajar con Flutter, pero esto no es un problema: solo necesitas tu propio enfoque para la multiplataforma.
Beneficios: una base de código, un equipo de desarrollo
Una única base de código reduce el tiempo de prueba.
El motivo de los errores puede ser especificaciones técnicas difusas, falta de estados renderizados en el diseño, compatibilidad con versiones anteriores al actualizar el back-end. Es más fácil crear tales errores, porque necesita crear la mitad de tareas, y esto ya ahorra tiempo.
Puede buscar errores y verificar características en una plataforma: con un alto grado de probabilidad, se repiten en ambas plataformas; después de todo, hay una implementación.
La lógica de las nuevas funciones en ambas plataformas también es la misma, ya que se escribe el mismo código: probar procesos complejos dentro de una aplicación se reduce a probarlos en una plataforma y confirmarlos en otra. Realizamos un ciclo completo de actividades en una plataforma: hacemos pruebas exploratorias, ejecuciones de funciones, humo / cordura / completo, analizamos comentarios. Después de eso, solo queda confirmar la calidad mediante pruebas exploratorias en otra plataforma. Este enfoque ahorra 1,3 veces el tiempo de prueba lógica.
, , , : , . , .
, (, iOS), , (Android), event .
Si los ensamblajes para ambas plataformas deben entregarse al cliente el mismo día, salen a la misma hora y solo hay un ingeniero de control de calidad en el proyecto, puede que no haya tiempo suficiente para la verificación en el desarrollo nativo: el ciclo de prueba debe realizarse en ambas plataformas por separado. Ahorramos tiempo probando aplicaciones multiplataforma: las pruebas de regresión de ambas plataformas se realizan en un solo ciclo.
Intentamos evaluar aproximadamente las pruebas de dos proyectos similares, uno en Android e iOS nativos, el segundo en Flutter, y los comparamos apicalmente.
El análisis y las pruebas se realizaron en un dispositivo iOS y un dispositivo de plataforma Android. Como puede ver en la práctica, Flutter realmente da una ganancia de tiempo, aunque no dos veces. Esto es comprensible: no puede eliminar completamente las pruebas en una de las dos plataformas. Digan lo que digan, tienen diferente especificidad y se centran en el usuario.
|
|
IOS nativo
|
Android nativo
|
Flutter Android + iOS
|
| Recuperación de contraseña
|
2h
|
2h
|
3 h 20 min
|
| Autorización
|
1h 30m
|
1h 30m
|
2 h 20 min
|
| Notificaciones push
|
2h
|
2h
|
4h
|
Cuando se prueba una función lista para usar que no afecta por completo las características específicas del sistema operativo y no está escrita a la medida para cada plataforma por separado, el tiempo para verificar una aplicación Flutter en ambas plataformas se reduce entre 1.3 y 1.5 veces. Por ejemplo, las funciones de autorización y recuperación de contraseña que no tienen un comportamiento específico en diferentes plataformas reducen el tiempo de prueba de la versión de Flutter en 1.3 veces.
En cuanto a las funciones que requieren un comportamiento personalizado de cada plataforma, no debe esperar una reducción en el tiempo. Se espera que el comportamiento de iOS y Android sea diferente, lo que significa que ambas plataformas deben probarse por completo y por separado. Por ejemplo, a menudo es necesario probar las notificaciones push en ciclo completo en ambas plataformas debido a las diferencias en los permisos, trabajar con la conexión de notificaciones, configuraciones de empuje para enviar notificaciones en iOS y Android, así como otras sutilezas de implementación, para que el trabajo habitual del usuario con notificaciones sea compatible. Se respetaron los conocimientos tradicionales y el diseño.
Es más fácil organizar la comunicación dentro del equipo.
Cuando hay mucha gente en el proyecto, es difícil organizar el proceso para que no pasen ni las sutilezas más pequeñas. Especialmente si hay muchas mejoras por delante, implementaciones de nuevas funciones y cambios en general. La mayoría de los problemas se resuelven cuando el equipo de desarrollo es uno.
Primero, es más fácil probar una aplicación implementando un solo comando que trabajar con dos implementaciones diferentes en dos plataformas. El profesional de aseguramiento de la calidad está, por supuesto, interesado en tener información completa sobre el estado de la aplicación, tanto en la plataforma iOS como en la plataforma Android. Es más fácil cuando se trabaja con Flutter.
En segundo lugar, hay un punto importante en el desarrollo nativo: sobre los cambios que una plataforma ha aprendido y aceptado, es necesario notificar a la otra plataforma, que a veces se olvida o se pierde en el transcurso de cambios grandes e intensivos. No existe tal problema al desarrollar aplicaciones de Flutter: solo hay un equipo, es decir, una tarea de revisión se aplica a ambas plataformas.
Nos encanta probar las aplicaciones de Flutter
Ser parte de una comunidad genial
Para nosotros, un nuevo marco es una ventaja: resolviendo problemas no estándar, ampliamos nuestros horizontes. Encontramos muchos errores interesantes y únicos que desarrollan nuestras habilidades y capacidades al probar aplicaciones.
Al mismo tiempo, los desarrolladores de la comunidad Flutter-framework brindan rápidamente comentarios sobre los problemas identificados, mejoran la biblioteca y nos permiten contribuir al proyecto: estamos avanzando juntos y es bueno.
Sea un especialista
Al trabajar con aplicaciones multiplataforma, es importante tener en cuenta las diferencias en los sistemas operativos y no perder el enfoque en la especificidad de la plataforma. Buscar y ver las diferencias donde deberían ser mínimas en teoría, aprender algo que nunca antes había encontrado: ese trabajo aumenta la profesionalidad.
Al desarrollar y probar aplicaciones nativas, es imposible crear una aplicación de iOS desde, por ejemplo, Android Studio o Visual Studio Code. Cuando se trabaja con Flutter, el IDE es el mismo para Android e iOS. Eso es genial.
Sea independiente
Al trabajar con Flutter, en Surf nos enfrentamos a proyectos muy diferentes: desde el comercio electrónico hasta la banca. La práctica ha demostrado que un ingeniero de control de calidad puede probar ambas plataformas sin ayuda. Es necesario conectar a otro especialista solo más cerca del lanzamiento, cuando aumenta el ritmo de trabajo y se agota el tiempo para completar las tareas.
Flutter - un paso adelante
Probar aplicaciones multiplataforma no es difícil. A veces es incluso más rápido y conveniente que trabajar con nativos. Todas las dificultades que uno puede enfrentar no se superponen a la conveniencia y las ventajas.
La experiencia en el desarrollo y la prueba de aplicaciones Flutter le ha demostrado a Surf que este marco es un gran paso adelante.