Una sinfonía en C#

Un pequeño aporte a la comunidad de habla hispana.

Testing continuo con Qunit, Phantom y Grunt

Voy a mostrar un lindo ejemplo de la combinación de tres herramientas:

  • QUnit
  • PhantomJs
  • GruntJs

La idea es utilizarlas en conjuto para poder hacer testing continuo, es decir, que mientras uno va programando (con TDD) los test se ejecuten automáticamente.

Las herramientas

Vamos a usar QUnit para el unit testing de Javascript, y PhantomJs para ejecutar los test sin necesidad del navegador, luego vamos a agregar GruntJs para que todo esto se haga automáticamente.

Si bien tal vez no sea la mejor forma de hacer esto, es un buen ejercicio de integración. Manos a la obra.

Qunit

Antes que nada vamos a crear un par de carpetas y agregar QUnit al proyecto, para esto creamos una página html con el siguiente contenido según se indica en el sitio de QUnit

<!DOCTYPE HTML>
<html lang="en-US">
<head>
	<meta charset="UTF-8">
	<title></title>
	<link rel="stylesheet" href="../js/vendor/qunit/qunit/qunit.css"/>
	<script type="text/javascript" src="../js/vendor/qunit/qunit/qunit.js"></script>
</head>
<body>
	<div id="qunit"></div>
</body>
</html>

Vemos que funciona de maravillas

image

Con eso es suficiente, ahora vamos a escribir algunos tests para probar.

module("calculadora");

var calculadora = new Calculadora();

test("suma", function(assert){
	var resultado = calculadora.sumar(4,3);
	equal(resultado, 7);
});

Simple, creamos el objeto Calculadora y agregarmos al html de test la referencia al test que acabamos de crear y al archivo que contiene la calculadora.

<!DOCTYPE HTML>
<html lang="en-US">
<head>
	<meta charset="UTF-8">
	<title></title>
	<link rel="stylesheet" href="../js/vendor/qunit/qunit/qunit.css"/>
	<script type="text/javascript" src="../js/vendor/qunit/qunit/qunit.js"></script>
	<script type="text/javascript" src="../js/calculadora.js"></script>
	<script type="text/javascript" src="fixture.js"></script>
</head>
<body>
	<div id="qunit"></div>
</body>
</html>

El archivo calculadora.js sería algo así:

Calculadora = (function () {

	var Calculadora = function () {};

	Calculadora.prototype.sumar = function (a, b) {
		return a + b;
	};

	return Calculadora;
}());

Si recargamos la página de prueba vemos que el test pasa

image

Ok, pero esto no es TDD, si quisiéramos hacerlo, escribiríamos el test primero, luego el método “sumar” y recargaríamos a mano cada vez la página de prueba, vamos a ver cómo hacemos para no tener que utilizar un navegador.

PhantomJs

PhantomJs es un navegador sin UI, es decir, no vamos a ver qué se muestra en pantalla, pero no importa, porque nos alcanza con que nos muestre un resultado por consola, para poder usarlo con QUnit, tenemos que utilizar un adaptador, que no es más que un Javascript que le dice a Phantom que cargue la página de test y muestre el resultado en la consola, algo así sería

image 

Para esto tenemos que instalar el paquete phantom de node y el paquete qunit-phantom-runner

npm install phantomjs
npm install qunit-phantomjs-runner

Y ejecutar

node node_modules\phantomjs\bin\phantomjs node_modules\qunit-phantomjs-runner\runner.js test\index.htm

Básicamente llamamos a Phantom le pasamos la ubicación del runner y después el nombre de nuestro archivo bajo test.

Bien, esto funciona, como imaginarán si un test falla nos lo indica, perfecto. Hasta ahora es lo mismo de antes pero sin llamar al navegador, faltaría hacer que se ejecuta cada vez que se modifica un archivo.

Ahora Gruntjs

Para esto vamos a usar la tarea watch de grunt y un pequeño gruntfile.js que diga que cuando cambie algunos de los archivos de testing se ejecute el comando anterior, algo así:

module.exports = function(grunt){
	grunt.initConfig({
		watch:{
			files:['test/*.js'],
			tasks: []
		},
		
	});
	
	grunt.loadNpmTasks("grunt-contrib-watch");	
};

Con esto configuramos la tarea watch, ahora falta invocar a Phantom, podemos hacerlo de varias maneras, en este caso voy a utilizar la tarea shell de grunt para hacerlo, y quedaría así:

module.exports = function (grunt) {
	grunt.initConfig({
		watch : {
			files : ['test/*.js'],
			tasks : ['shell:phantom']
		},
		shell : {
			phantom : {
				command : 'node node_modules/phantomjs/bin/phantomjs node_modules/qunit-phantomjs-runner/runner.js test/index.html'
			}
		}

	});

	grunt.loadNpmTasks('grunt-contrib-watch');
	grunt.loadNpmTasks('grunt-shell');
	grunt.registerTask('default', ['watch']);
};

Y eso sería todo, configuramos la tarea watch para que mire el directorio donde están los test (tal vez deberíamos agregar el directorio del código) y le decimos que ejecute la tarea shell que ejecuta el comando que invoca a Phantom.

Por último decimos que la tarea por defecto es watch y listo, ejecutamos

grunt

image

Y listo, mágico, cada vez que hacemos un cambio en algún archivo de test (o lo que queramos, claro) se ejecuta Phantom con el adaptador para QUnit y corre los test.

Dejo el link con el código funcionando en github.

Nos leemos.

Tips de Javascript: String multilínea

En ocasiones necesitamos escribir un string largo en nuestro código, no viene al caso el por qué.

La forma más común de solucionarlo sería esta:

var texto = 'Hola a todos, este es un texto largo'
+ ' largo que intento poner en varias '
+ 'líneas pero javascript no soporta esto o si?';

console.log(texto);

Por supesto que esto funciona, pero es un poco engorroso y feo además.

Bien, me he sorprendido al saber que mucha gente no sabe que Javascript tiene una sintáxis especial para esto, y es sencillamente agregar una barra invertida al final de cada línea, de este modo:

var texto = 'Hola a todos, este es un texto largo\
largo que intento poner en varias \
líneas pero javascript no soporta esto o si?';

console.log(texto);

Un detalle importante es que sólo funciona con comillas simples.

Como vemos además de ahorrarnos de poner las comillas y los signos + en cada línea que un poco más compacto.

Nos leemos.

Tips de Javascript: para qué sirve setTimeout = 0?

Tal vez hayan visto este código:

setTimeout(function(){
 //hacer ago
}, 0);

Básicamente es un timeout (es decir, esperar un tiempo y llamar al callback) con el tiempo en 0. Uno pensaría que esto se debe ejecutar inmediatamente, pero no es así, de hecho, el tiempo que puede tardar en teoría podría ser infinito, veámos un ejemplo:

console.log( +new Date );
	
setTimeout(function(){
	console.log( + new Date );	
		console.log("timeout");
}, 0);

image

Este pequeño código escribe los milisegundos y nos permite ver cuánto tardó la ejecución.

Digamos que es casi inmediato, en este caso tardó unos 21 ms en ejecutarse. Veamos el siguiente ejemplo.

console.log( +new Date );

setTimeout(function(){
	console.log( + new Date );	
	console.log("timeout");
}, 0);


for(var i = 0; i< 1000; i++){
	console.log("");
}

image

Esta vez agregamos un loop después del setTimeout y ahora tardó casi 200ms, si miramos con atención vemos que en realidad el código del callback se ejecutó recién después de que terminó de ejecutarse el loop, nada hace pensar que esto debería pasar, un pensaría que el tiempo debería ser similar al anterior y encontrarnos con el mensaje en medio de la ejecución del loop, pero no es así.

El call stack de Javascript

Javascript es single thread, es decir, hace una única cosa a la vez, lo que hace es poner las tareas en una pila de llamadas (el famoso stack overflow ocurre cuando sobrepasamos su límite) y las va ejecutando de a una.

En el caso de los timer (y otras cosas), lo que ocurre es que se colocan en el call stack (1) y luego se llama a las funciones especiales conocida como Web Apis (2) (son funciones especiales del navegador, en este caso cuentan el tiempo).

Luego que el intervalo se cumplió se colocan en el call queue indefinidamente (3) hasta que el call stack se encuentre vacío, entonces se pasa la función callback (en nuestro caso console.log(-new Date) ) al call stack y se ejecuta (4).

image

En nuestro ejemplo Javascript puso primero en el call stack nuestro setTimeout y detectó la llamada a funciones de Web Apis, luego de transcurrido el tiempo (0 ms) puso el callback en call queue; cuando el call stack quedó vacío (terminó de ejecutarse el bucle for) lo puso en call stack y lo ejecutó.

Es decir que: usar setTimeout con el interval en 0 es equivalente a decir “ejecutá esto cuando no haya nada más por ejecutar” y eso puede ser ya, o dentro de un tiempo mayor.

Nos leemos.