¿Test automáticos de aplicaciones Web con Node, Selenium y Chrome?

Selenium es una suite de automatización de pruebas. Es robusta, tiene más de 10 años en el mercado y es la herramienta open source estandard ‘de facto’. Se compone de dos partes:

  • Selenium WebDriver. Es un paquete que se ejecuta como un servicio (un .jar) para que nuestra aplicación de testing acceda, permitiendo a nuestro código de prueba interaccionar con el navegador.
  • Selenium IDE. Es una extensión para Firefox que permite interactuar con nuestra página y guardar las secuencias de comandos para incorporarlos a nuestras pruebas automáticas.

Un problema que nos encontramos en BIZLOGIC es que si lo que queremos probar es una aplicación enfocada a Chrome (por ejemplo, porque utilizamos elementos de ECMAScript 6 tanto en el navegador como en el servidor nodeJS y apostamos por el motor V8) la herramienta está enfocada a Firefox.

Aunque podemos utilizar ChromeDriver para interactuar con nuestro navegador Chrome, y así asegurar que las pruebas se ejecutan en el escenario final. Otro problema es el lenguaje con el que se programan los script es Java o Python. No es que tenga nada en contra de estos lenguajes, pero una vez se ha hecho una apuesta fuerte por EMCAScript no le veo el sentido a utilizar un lenguaje diferente para realizar las pruebas, si además, como dictamina el TDD las pruebas se deben de programar como mínimo a la vez que el código.

Para solucionar el problema tenemos el frameworkd WebDriver.io, que han montado un conector desde node.js/javascript. Esto nos permite escribir las pruebas con JavaScript y NodeJS, pudiendo tener un poco más emparentado la plataforma de pruebas y la aplicación a probar. De hecho sin mucha dificultad se puede seguir el tutorial para tener montado un proyecto de testing de nuestra web.

Pero hay otro problema: imaginemos nuestro desarrollador experto en fron-end, que tiene una gran soltura a la hora de manejar la estructura BOM y DOM de la página con jQuery. Y a la hora de escribir las pruebas… ha de escribir a mando cosas que hacia años que no usaba, como

document.getElementById(...)

!! Estamos escribiendo pruebas que acceden elementos de la página y lo tenemos que hacer de una manera completamente diferente a la programación al no disponer de jQuery.

Para superar este otro problema existe una librería NPM que extiende (un poco solo) webdriver.io con una pseudointerficie jQuery para al menos disponer de selectores.

Otra piedra en el camino es que al utilizar el IDE (que solo funciona con Firefox) éste solo nos permite exportar los scripts a diferentes lenguajes… pero no a JavaScript.

Screen Shot 2016-09-26 at 17.03.26

Personalmente cuando algo es muy complicado pierdo el interes, y en este caso se ha estado evaluando como montar una solución con Selenium + Webdrive.io + webdriverio-kquery. Depués de instalar los más de 20 paquetes NPM necesarios (con el consiguiente cuelgue de Explise durante un rato) al final tenemos que los scrips o se han de picar a mano, o traducirlos de otro lenguaje a JavaScript, pero teniendo que aprender la notación y los secretos de la API de WebDrive

var webdriverio = require('../../build/index');

var options = {
    desiredCapabilities: {
        browserName: 'chrome'
    }
};

var client = webdriverio.remote(options);

client
    .init()
    .url('https://news.ycombinator.com/')
    .selectorExecute('//div', function(inputs, message){
        return inputs.length + ' ' + message;
    }, 'divs on the page')
    .then(function(res){
        console.log(res);
    })
    .end();

¿Y el beneficio? al final el framework de pruebas nos proporciona un runner de pruebas (que es un simple loop que va ejecutando los tests alojados en ficheros .js) y algunas utilidades de Promise para facilitar el no perderse con los callbaks y el esperar a que los elementos se carguen:

client
    .init()
    .url('http://www.google.com/')
    .waitForVisible('//input[@type="submit"]', 5000)
    .then(function(visible){
        console.log(visible); //Should return true
    })
    .end();

Al final, y contraviniendo la premisa “no inventar la sopa de ajo”, se ha montado un mini-sistema de testing basado en una página con un IFRAME que carga la página a probar, en apenas 6 horas. Que mostraremos en otro artículo.

Solo notar que en este caso las pruebas son locales y no remotas. En ese caso nos haría falta jugar con las cabeceras ALLOW-ORIGIN para poder ejecutarlas.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.