Configurar TravisCI Para Que Corra Nuestros Test

Configurar TravisCI para que corra nuestros test

Que pasa muchachos?

Hoy vengo con un artículo que me gusta especialmente. Los que me conocen a nivel profesional ya sabrán que me encanta la integración continua, desde que me inicié con Jenkins hasta ahora que para cada proyecto que hago me preparo mi modulo de test y lo engancho con TravisCI. Las maravillas que nos brinda la integración continua nos permite tener siempre una versión depurada de nuestro código y libre de bugs. En el fondo, la integración continua, consiste en hacer un despliegue de control cada vez que vamos a subir a producción y así tenerlo todo bien testeado y probado antes de llevarnos nuestro código a un entorno real.

Como os he dicho, conocí la integración continua con Jenkins. Trabajaba en un proyecto demasiado grande en el que había configuradas varias tareas para el servidor de integración, pero para que os hagáis una idea, cuando hacíamos un pase a producción y mezclábamos la rama de staging contra master, el servidor de Jenkins se encargaba de hacer lo siguiente:

  • Cogía los scripts con la estructura de la base de datos y montaba una.
  • Cogía los scripts con los inserts e iba alimentando a la base de datos.
  • Clonaba el código fuente y minificaba archivos CSS y Javascript.
  • Pasaba un análisis Sonar para evaluar la calidad del código.
  • Hacía un primer pre-compilado temporal de la aplicación.
  • Corría los test unitarios y funcionales.
  • Preparaba la documentación.
  • Compilaba la versión definitiva para el servidor de producción.

Obviamente todo esto lo hacia en varias fases y con distintos servicios enganchados (Jenkins, Maven, Ant, Git, Sonar…), pero toda la potencia de la integración continua reside en la libertad para configurar todas las tareas que te den la gana.

Para este artículo no vamos a hacer una configuración tan complicada, nos dedicaremos a realizar una que, cuando se haga un commit en nuestro repositorio, el servidor de integración continua, de ahora en adelante TravisCI, se encargue de clonar el proyecto y ejecutar los test que tenemos en el directorio de test.

Y para ilustrar el ejemplo, vamos a montar un proyecto con las siguientes tecnologías:

  • Grunt: para el automatizado de tareas, en este caso nos interesan dos, la compresión de ficheros y el lanzamiento de la suite de test que prepararemos.
  • Uglify: para comprimir ficheros, en este caso haremos una versión minificada de nuestra librería.
  • NPM: para la gestión de dependencias.
  • jQuery: para el manejo del DOM.
  • qUnit: para la creación de test unitarios y funcionales.
  • TravisCI: para realizar el proceso de build e integración continua.
  • Github: para almacenar nuestro código fuente.

Comenzando. Instalamos NPM

Cómo he dicho mas arriba, NPM es un gestor de dependencias construido en NodeJs, por lo que necesitamos NodeJs si o si. Si aún no lo tenéis instalado en vuestro equipo lo podéis bajar desde aquí. Cuando ya lo tengáis bajado e instalado en vuestro ordenador, hay que instalar NPM y para ello hay que ejecutar en una terminal lo siguiente:

sudo npm install npm -g

Cuando acabe podéis mirar que se ha instalado correctamente comprobando su versión.

Versión de npm

Versión de npm

Y para inicializar un proyecto con NPM, tan solo tenemos que escribir npm init en una terminal y completar toda la información que nos pide para poder crear correctamente el fichero package.json.

Sobre este fichero nos encargaremos de definir el proyecto. Aquí indicamos el autor, el nombre del proyecto, licencia, repositorio público, versión, dependencias…

Además el fichero package.json será el encargado de decirle a nuestro servidor de integración continua que tareas ha de ejecutar y para ello tenemos que añadir lo siguiente:

    "scripts" : {
        "test": "grunt travis --verbose"
    },

Además, como decía, tenemos que añadir las dependencias que necesitamos en el proyecto, en este caso necesitamos grunt, qunit y uglify y para ello añadimos el bloque de devDependencies:

"devDependencies": {
    "grunt": "^0.4.5",
    "grunt-contrib-qunit": "^0.7.0",
    "grunt-contrib-uglify": "^0.11.0",
} 

A continuación os voy a dejar un packages.json de uno de mis proyectos para que veáis cuales serian sus opciones básicas. Podéis verlo desde mi repositorio de Github.

Definiendo nuestro fichero de tareas

Todas las tareas automatizadas que queramos llevar a cabo las tenemos que definir el fichero gruntfile.js que se situará en la raíz del proyecto pero antes de ello necesitamos instalar qunit y uglify y para ello desde la terminal vamos a hacer uso del gestor de paquetes NPM.

npm install qunit
npm install uglify-js

Al final la terminal nos tiene que escupir algo como lo siguiente:

Terminal después de instalar uglify

Terminal después de instalar uglify

Tal y como hemos indicado en nuestro packages.json, TravisCI necesita de una tarea específica para correr los test, en el packages.json la hemos llamado travis y para ello nuestro es necesario que definamos una tarea travis en nuestro gruntfile.js

module.exports = function(grunt) {
   grunt.initConfig({
    	pkg: grunt.file.readJSON('package.json'),    
    	qunit: {
            files: ['test/*.html']
    	},
    	qunit_junit: {
            options: {
                dest: '_build/test-reports'
            }
        }
   });

   grunt.loadNpmTasks('grunt-contrib-qunit');
   grunt.loadNpmTasks('grunt-qunit-junit');
  	
   grunt.registerTask('default', ['qunit_junit', 'qunit']);
   grunt.registerTask('travis', ['qunit_junit', 'qunit']);
};

Seteando nuestro fichero de TravisCI

Antes de crear nuestro fichero de configuración para TravisCI, es necesario loguearnos en la plataforma y decirle al servidor de integración qué repositorio queremos añadir. El login podemos (y deberíamos) hacerlo con github ya que es allí donde estamos dejando nuestro código.

Según la documentación de TravisCI, se necesita un fichero llamado .travis con todas las especificaciones necesarias para que sepa que hay que hacer.

Fichero de configuración de Travis

Fichero de configuración de TravisCI

Éste es un fichero de configuración mínima. En él estamos indicando que vamos a correr un proyecto construido con NodeJS y que su versión es la 0,10. Para más colmo, podemos controlar la ejecución del script indicando con la directiva before_script que instale en el servidor grunt antes de correr los test. Como he dicho esto es lo más básico que podemos poner en el fichero de configuración, sin embargo, tenemos miles de opciones mas para customizar nuestra build, puedes leerlo aquí.

El fichero de configuración ha de situarse en la raíz del proyecto con el nombre de .travis.yml y no hace falta que hagamos nada mas ya que según la documentación de TravisCI, por defecto va a buscar cualquier tarea que se llame travis y eso ya lo hemos definido un poquito mas arriba, en nuestro gruntfile.

Después de todo esto, cuando hagamos un commit a nuestro repositorio, TravisCI va a detectar que hay cambios y va a lanzar la ejecución del script que construye nuestro build. Si veis la consola dentro de TravisCI, veréis que hace muchísimas cosas, setea el entorno, instala Grunt, minimifica archivos css y js… pero lo que nos interesa es la ejecución de los test.

Test Suite Case OK

Test Suite Case OK

Conclusión

Está claro que no se necesitan de todas estas herramientas para construir software, es más, todos estos conceptos, herramientas y ayudas llevan “muy poco tiempo” entre los desarrolladores en comparación con otras áreas de la informática, sin embargo, cuando estamos trabajando en un proyecto que tiene la capacidad de escalar rápido, necesitamos “olvidarnos” de ciertas tareas para focalizarnos en lo realmente importante, la construcción de software de calidad.

Mucha gente está en contra de la realización de test funcionales/unitarios, por lo general, esa gente van a ser gestores de proyectos a los que solo les importa los deadlines y que te ven como un recurso mas, pues bien, ni puto caso y a aplicar TDD to the limit.

A continuación os dejo con un vídeo de un desarrollador que ha hecho un walkthrough sobre como testear javascrit con TravisCI, no hay desperdicio 😉

Gorka Muñoz Andrés

Me llamo Gorka Muñoz y soy un desarrollador melómano. Combino a la perfección la búsqueda de nuevos grupos con la pasión por la tecnología. Desde chiquitito me ha gustado la programación, ahora que soy mayor estoy metido en el mundo del SEO sin olvidarme del /Dev.

This Post Has One Comment

  1. José Maria

    Buenos días Gorka.
    Solo indicarte que llevo bastante tiempo siguiéndote y creo sinceramente que haces un block muy interesante el cual a mí en alguna ocasión me ha servido bastante.
    Te animo a que sigas.
    Saludos.

Deja un comentario

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