Columna por: Rodrigo Ruiz, CTO de Imagemaker
A partir de este trimestre, enfocaremos nuestros esfuerzos de divulgación, los workshops y los artículos en una tecnología o tema, de esa forma podremos proveer una experiencia consistente y de mayor profundidad, que además se puede prolongar por más tiempo.
Queremos que el primer tema sea calidad y automatización.
La calidad es un tema muy importante. Subvalorado, pero muy importante. Hablando desde mis fobias, sin aseguramiento de la calidad, esa ala del avión que ves que se dobla más de lo que te hace sentir cómodo, simplemente se partiría en dos, la manilla de la puerta del baño del avión se quedaría en tu mano (tengo una de esas en mi colección btw) y las llantas del tren de aterrizaje durarían menos de lo que duró la adaptación de cowboy beebop en netflix.
Estamos todos de acuerdo en que el aseguramiento de la calidad es un tema crítico en nuestra industria, sin embargo, vemos tantos malos ejemplos todos los días. Es algo que todos dicen hacer, pero muy poco realmente hacen bien ¿Y por qué?
Bueno, entre otras cosas porque es una lata.
Es por eso que siempre he visto a los QA como una especie de santos, que todo lo toleran y todo lo perdonan. Son personas que tienen que descender todos los días al borde de la locura y volver sin ser afectados (bueno, conozco algunos que ya están mostrando síntomas de deterioro ;P jejeje )
¿Qué pasaría si hacemos que parte de su trabajo sea más llevadero? ¿Y si hacemos que cualquiera pueda aportar a la calidad del código, incluso si no sabe programar?
Quiero presentarte a Q-Jitzu, una herramienta open source que desarrollé hace un par de años para simplificar las tareas de automatización de aplicaciones móviles y sitios web. Está basada en selenium y appium, con un lenguaje de programación propio y un transpilador que produce código java directamente. De esta manera, siempre sabes qué se está ejecutando.
La filosofía detrás de Q-Jitzu es que todo el equipo debe aportar a la calidad y contribuir a la cobertura de las suites de regresión, mediante herramientas intuitivas y divertidas de usar.
Q-Jitzu se basa en las siguientes premisas:
Código fácil de entender, ligero y que fomente la reutilización y la mantención
Un entorno de desarrollo estándar (Eclipse), con soporte para syntax highlight, marcar errores de sintaxis, autocompletado, entre otros.
Que gestione la ejecución de pruebas en paralelo y de alto volumen.
Que funcione en dispositivos reales y/o emuladores
Que se integre fácilmente en pipelines de devops
Que soporte TDD y BDD
Que soporte test unitarios, suites y precondiciones
Que pueda cargar datos desde archivos externos
Todo eso suena muy bien, estarás diciendo, pero sin imágenes no hay atención:
Usando Selenium + Appium, un test de smoke de una app luce generalmente así:
Este código no tiene varias cosas importantes que omití por brevedad (Listado de capabilities del device, limpieza posterior al test, etc.)
Mientras que luego de definir brevemente la estructura de tu pantalla a probar, el código equivalente en Q-Jitzu es:
¡Eso es, así de simple! Fíjate que la funcionalidad de crear smoke test está incorporada en el lenguaje mismo.
Hay varias cosas pasando en el test de la primera imagen, creado a mano con Selenium:
La adquisición manual del driver y el seteo de capacidades y devices hace que sea difícil el seteo de clusters de pruebas y el manejo de capabilities. Por supuesto ahora tú te tienes que hacer cargo del ciclo de vida del driver
El uso extensivo de constantes y strings hace que el código se vuelva difícil de leer y manejar
El uso de asserts hace que sea difícil para un principiante saber exactamente qué se está probando, el api de selenium, particularmente verboso no facilita la tarea.
Es cierto que todos esos problemas se pueden resolver, pero también es cierto que deberías enfocarte en hacer las pruebas, no en crear código boilerplate que haga que tus pruebas sean más mantenibles. Q-Jitzu maneja todo eso en el diseño del lenguaje mismo.
Si quisieras como ejercicio hacer la misma prueba de smoke, sin usar el feature “smoke” del lenguaje, tu código se vería así:
Fíjate qué distinto. No hay llamados a elementos, se pregunta directamente si un elemento existe, se pregunta si el contenido de un elemento es el esperado, entre otras. Todo es explícito.
Otra cosa de la que probablemente ya te diste cuenta, es que el lenguaje refuerza el uso de definiciones de estructura (FirstTest.ui. ), por lo que poner strings en duro para referirse a identificadores o texto dentro de la app, no se permite. Por el contrario, se hace disponible una estructura reutilizable que puede ser referenciada posteriormente dentro de otros tests. Generalmente existe una estructura por pantalla en tu app, por ejemplo, la primera pantalla se llama “FirstTest” y su definición es esta:
Fíjate que “FirstTest” está dividida en dos secciones, “ui” y “data”.
La estructura “ui” contiene todos los mecanismos para encontrar un elemento dentro de una pantalla (id, accessibility, xpath, class o name). Fíjate que existe un identificador para android (droid id) y para ios (ios id), así como para la web (no se muestra en la imagen), eso te permite usar distintas estrategias de ubicación de elementos dependiendo de la plataforma.
La subestructura “data” contiene los textos y contenidos varios de los elementos.
Hay otra ventaja que no he mencionado, pero probablemente ya notaste: Exactamente el mismo código de pruebas sirve para todas las plataformas. El compilador se encarga de generar las estructuras necesarias automáticamente.
Por supuesto la interactividad es primordial a la hora de automatizar. Para esto el lenguaje tiene incorporadas varias características:
En la primera línea, se le envía el texto “Hola” al editor de texto de la app, mandando tecla por tecla. La segunda línea (adivinaste) hace click al botón y la tercera simplemente espera 3 segundos a que la aplicación haga algo.
Y bueno, ¿cómo luce un test de smoke reutilizable en Q-Jitzu?
Los test unitarios se pueden agrupar en suites de test, cada una con un “Tema” (en este caso “Suite de ejemplo”) Estos “temas” te permiten identificar los test en los logs de ejecución. Cada test puede tener un orden de ejecución y ser desactivados temporalmente.
Al estar basados en JUnit, puedes usar todas las herramientas de análisis y cobertura que ya usas hoy.
Ahora, y para cerrar el negocio, qué dirías si te dijera que además Q-Jitzu es capaz de conectarse automáticamente a tu app y crear automáticamente las definiciones y test de smoke por ti, de manera que sólo tengas que centrarte en agregar las pruebas que realmente aportan?
Así es, el test de la imagen anterior se hizo automáticamente, con 1 solo click.
Sé que es bastante para digerir en una sola lectura, y no hemos empezado a hablar de las características más interesantes de la herramienta (pre condiciones, puedes guardar el estado de una aplicación para no empezar cada test desde cero, ejecuciones masivas y paralelas entre muchas máquinas por nombrar algunas), por lo que estamos planeando un workshop práctico para que conversemos en detalle y en profundidad.
En resumen, Q-Jitzu hace que la tarea de automatizar aplicaciones y sitios web sea mucho más liviana, y en muchos casos automática. Q-Jitzu no solo te va a hacer a ti y a tu equipo más productivo... ¡te va a ayudar a elevar la calidad de tus desarrollos con un esfuerzo mínimo!
Si quieres conocer más de esta solución, te invitamos al Webinar en el que presentaremos esta plataforma:
