StrangePlanet » Blog

javascript

Use Travis CI & Coveralls for a web frontend library

8 mars 2015 by Mistic Leave a Comment

(Cet article n’est disponible qu’en Anglais)

Update April 2th 2015 : I created a Grunt task to simplify the bridging between Blanket.js and Coveralls.io, you can find it here: grunt-qunit-blanket-lcov.


With QueryBuilder I did/still do a lot of experiments in build and test tools. It all began with a small Grunt to automate the minification process. Then I added QUnit tests, automatically run on Travis CI. And today I added test coverage evaluation with Blanket.js pushed to Coveralls.

As I spent many hours to configure my project, I wanted to share my experience, in a step-by-step guide about how to test my web frontend library on Travis CI and Coveralls ?. I will only talk about fontend libraries which involve HTML & CSS in addition to JavaScript, because it raises new issues.

Introduction

I will make the following assumptions: your project is hosted on Github, you know how to use Grunt and you already have QUnit tests. If not I suggest you read the Getting started Grunt guide and the QUnit introduction to unit testing.

Here are the points addressed in this guide :

  • Run Qunit tests with Grunt
  • Publish your project to Travis CI
  • Hook Coveralls to Travis CI

An headless web browser

QUnit is basically a web application, it requires a web browser to run, thus it can’t run on NodeJS which does not have a display view. But our goal is to automatically run our tests suite on a very light virtual machine without Firefox or Chrome and still get significant results.

The solution is PhantomJS, an headless web browser ; that means it is capable of « compiling » a complete webpage, run JS scripts, trigger events, etc, without any rendering view. But running our QUnit page on Phantom and parsing the results would be a pain in the a** without this Grunt QUnit tasks. It basically spawns a new PhantomJS process for each tests suite and returns a formatted report in the console.

Installing

So in order to run the QUnit tests with Grunt, start to add « grunt-contrib-qunit » to your project :

$ npm install grunt-contrib-qunit --save-dev

Good. Now it’s time to edit your « Gruntfile.js » file. Add the following in the initConfig object :

qunit: {
    all: {
        options: {
            urls: ['tests/index.html'],
            noGlobals: true
        }
    }
}

And declare the new tasks :

grunt.loadNpmTasks('grunt-contrib-qunit');

grunt.registerTask('test', [
    'qunit'
]);

And it’s done ! You should be able to run grunt test from the console and see the tests results.

$ grunt test
Running "qunit:all" (qunit) task
Testing tests/index.html ............OK
>> 31 assertions passed (487ms)

Done, without errors.

Time to move on.

Continuous integration with Travis

Continuous integration consists in running your tests automatically everytime you push new commits. This way you are always sure that you didn’t break anything (and if it’s not the case you receive a nice email with insults !). The other big advantage is that if you use Github and Travis CI together, tests will be run for pending pull-request too and you will be able to quickly see if it’s a breaking change or not.

Installing

Starting with Travis CI is very easy, there are only two things to do.

Update your package.json file to declare the test script :

"scripts": {
    "test": "grunt test"
}

Create a « .travis.yml » file with the following content :

language: node_js
node_js:
  - "0.12"
before_install:
  - npm install -g grunt-cli
install: npm install

This tell Travis CI that your are running your tests on NodeJS 0.12 and ask it to install Grunt and your Node dependencies before running the tests.

If your tests rely on Bower dependencies you need to add :

before_install:
  - npm install -g bower
before_script:
  - bower install

Registering

Final step : register your project on Travis CI. Once logged to the Travis website with your Github account go to your profile and enable continuous integration on your project. I suggest you go to the project settings and enable « Build only if .travis.yml is present » to prevent useless builds of forks who removed the file.

Then you just have to push some commits to trigger a build and see the result online. You can even get a nice badge to add to your README : .

Time to evaluate your unit tests !

Code coverage for winners

Ok your unit tests are all passing, but are they relevant ? Do you test everything ?

That’s what a code coverage tool can tell you, it analyses which parts of your code were executed during the unit tests and return a coverage percentage, if you are not at 100% then you didn’t test everything. Caution a coverage of 100% does not mean you tested everything either, it just means that every bit of code where executed, you can still have bugs for not intended cases.

Installing

In order to calculate code coverage of our QUnit suite we will use Blanket.js, which is great because it require zero configuration.

First, install Blanket :

$ bower install blanket --save-dev

Next, edit your tests suite by adding after « qunit.js » :

<script src="../bower_components/blanket/dist/qunit/blanket.min.js"></script>

… and adding data-cover to the scripts your are testing :

<script src="../dist/query-builder.js" data-cover></script>

Then open your tests page in your browser, check « Enable coverage » and see the coverage results at the bottom of the page. You can even click on the file name and see which part of the code are not tested.

So you know your code is covered at 85%. How to automatically publish the result on Coveralls ?

Bridging

That’s where the tricky part starts. We need to get the Blanket results and send them to Coveralls API, but these results are only available inside PhantomJS process (remember ? we run the tests in an headless browser).

Hopefully Blanket has a module to export its report in a format comprehensive to Coveralls, and we also have a grunt task to upload data to Coveralls. Let’s plug everything together.

First step : modify you tests suite to send formatted coverage results back to PhantomJS, add this after other scripts :

// LCOV reporter, only if called with "lcovReport" parameter
if (location.href.match(/(\?|&)lcovReport($|&|=)/)) {
   blanket.options("reporter", "../bower_components/blanket/src/reporters/lcov_reporter.js");
   blanket.options("reporter_options", { toHTML:false });

   // send results to PhantomJS
   QUnit.done(function() {
      alert(JSON.stringify(['qunit.report', window._$blanket_LCOV]));
   });
}

Modify the qunit task in « Gruntfile.js » to use this url : tests/index.html?coverage=true&lcovReport.

Also add an event handler to get coverage data and save them in a file :

grunt.event.on('qunit.report', function(data) {
    grunt.file.write('.coverage-results/core.lcov', data);
});

Install Grunt Coveralls module :

$ npm install grunt-coveralls --save-dev

Add the coveralls task to « Gruntfile.js » :

coveralls: {
    options: {
        force: true
    },
    all: {
        src: '.coverage-results/core.lcov',
    }
}

And finally configure « .travis.yml » to send coverage report to Coveralls.io on success :

after_success: grunt coveralls

Registering

You just have to register on Coveralls with your Github account, go to your profile and add your repository. As you use public Travis CI for the build you don’t need to add any special configuration.

If for some reason you need to push coverage results from your local computer you will have to add a « .coveralls.yml » with the token you can find on Coveralls website do not commit this file.

repo_token: xxxxxxxxxxxxxxx

Now everytime you push to your repository, tests will run on Travis CI and coverage results will be sent to Coveralls, which also offer you a nice badge for your README :

Bonus : code quality

In QueryBuilder I also use JSHint to prevent coding mistakes. In this bonus part we will add a Grunt task to make the build fail the code quality check does not pass.

Start by adding Grunt contrib JSHint :

$ npm install grunt-contrib-jshint --save-dev

Edit your « Gruntfile.js » to configure the task :

jshint: {
    lib: {
        files: {
            src: ['dist/query-builder.js']
        }
    }
}

… and declare the tasks :

grunt.loadNpmTasks('grunt-contrib-jshint');

grunt.registerTask('test', [
    'jshint',
    'qunit'
]);

Now grunt test will run JSHint in addition to QUnit, and the Travis CI build will fail if you forgot a comma or made a mess with callbacks !

$ grunt test
Running "jshint:lib" (jshint) task
>> 1 file lint free.

Bibliography

  • Building a Node.js project – Travis CI
  • Introduction to Unit Testing – QUnit
  • Automated Code Coverage Enforcement for QUnit Using Grunt and Blanket – Dave Cadwallader
Posted in: Développement, Tutoriels Tagged: coveralls, grunt, javascript, jquery, jshint, nodejs, qunit, travis-ci

Nouveau site

20 juillet 2013 by Mistic Leave a Comment

Cet été je suis en stage à Genève dans une boite de développement web, et pour me changer les idées (!) j’ai passé les soirées des trois dernières semaines à la réalisation d’un nouveau « site d’accueil » pour strangeplanet.fr.

L’accueil précédent était assez esthétique mais il n’y avait vraiment pas assez de place pour tout ce que je voulais y mettre, et surtout il s’affichait très mal sur smartphones et les petites tablettes tactiles (à l’époque je n’avais pas de smartphone).

J’ai donc décidé de tout recommencer depuis le début et prévoyant assez de place et en développant dans une optique responsive-design.
Cette nouvelle version est divisée en trois parties : l’accueil, présentant les news, mes derniers commits Piwigo et mes « likes » YouTube et Vimeo ; une section projets ou je présente les diverses chose que j’ai développé (c’est cette section qui faisait vraiment défaut à la version précédente) et une page d’à-propos avec diverses infos, mon CV et le formulaire de contact.

Techniquement j’ai utilisé pour la première fois les nouvelles balises HTML5 comme <nav> et <aside>, finalement ça ne change pas grand chose, il faut juste penser au vieux navigateurs qui ne les comprennent pas. J’ai aussi utilisé plein de CSS3, pour lequel j’ai d’ailleurs appris de nouvelles propriétés comme l’excellent box-sizing:border-box; et la fonction calc() (ceux qui les ont déjà utilisés comprendront ma joie).

Bonne visite !

Posted in: Développement, Perso Tagged: javascript, site web, SVG

[jQuery] highlightTextarea – pour surligner du texte dans un… textarea

17 février 2012 by Mistic 1 Comment

Voici mon tout premier plugin pour la bibliothèque jQuery que j’ai (presque) écrit tout seul. Je dis presque parce que la technique vient d’une proposition d’un certain Julien L sur Stack Overflow (merci à lui même si j’ai pas pu le contacter).

Ce plugin au doux nom de highlightTextarea permet de surligner du texte dans un textarea, ces grands champs de texte dans les formulaires HTML.

Démonstration :

La technique est assez simple : rendre le fond du textarea transparent et placer en dessous un conteneur avec le même texte mais dans lequel on applique un style CSS aux mots que l’ont veut surligner.
Ça se complique légèrement pour tout aligner correctement selon les propriétés du textarea (margin, padding, border, polices et taille d’écriture, présence ou non de la scroll-bar…) mais je suis sur que ça vous intéresse pas !

Pour une documentation complète sur l’installation et la personnalisation du plugin je vous laisse consulter la page dédié (en anglais) et quelques exemples supplémentaires.

Bon Javascript !

Posted in: Développement, Web Tagged: highlight, javascript, jquery, textarea

[PHP] Vérifiez la connexion aux sites externes !

3 novembre 2010 by Mistic Leave a Comment

De plus en lus de « gros » sites, surtout ceux ayant une portée communautaire, sont connectés par divers moyens à Twitter, Facebook, et dans un cas plus général à Google Adsense. Seulement que ce passe-t-il quand les sites en questions mettent du temps à répondre ?
Je suis sur que ça vous est déjà arrivé : vous chargez la page du dernier block-buster sur AlloCiné, ça fait déjà 30 secondes que vous y êtes, un coup d’œil dans la barre d’état En attente de http://www.googlesyndication.com/… £#%§¤@ !!!

Pourtant tous ces sites utilisent PHP ou une technologie semblable pour générer les pages, serait-il si difficile de vérifier la connexion aux sites en question avant d’injecter les divers Javascript dans la page ?

C’est ce que j’ai décidé de faire sur mes quelques sites (TM-ScreenMania et bientôt le nouveau site de UVME) et ceci de façon très simple en PHP :

$DispoGoogle = false;
if (($fp = @fsockopen('googlesyndication.com', 80, $errno, $errstr, 3)) != false) {
	fclose($fp);
	$DispoGoogle = true;
}

Le quatrième paramètre de la fonction fsockopen est le TIMEOUT, temps au bout duquel la site est considéré comme indisponible. Il ne reste plus qu’a tester $DispoGoogle avant d’ajouter les Javascripts AdSense à la page.

Ce n’est peut être pas la meilleure façon de procéder mais c’est surtout le principe que j’aimerais voir se généraliser, histoire de pas perdre trois plombes pour consulter les horaires de cinoche… (oui ça sent le vécu)

Posted in: Développement, Web Tagged: adsense, google, javascript, lenteur, php

Catégories

  • Créations (9)
  • Développement (16)
  • Général (1)
  • Perso (3)
  • Récits (5)
  • Tutoriels (3)
  • Web (8)

Articles récents

  • Use Travis CI & Coveralls for a web frontend library
  • Comment j’ai transformé un téléphone en moniteur système
  • jQuery QueryBuilder
  • [Piwigo] Un carrousel des dernières photos ajoutées
  • [Musique] Tarja: Colours in the Dark

Étiquettes

bateau c++ calcaires carbon chevrolet cité corvette désespoir encodage escalade extension font forever forêt galerie graphique image javascript jquery mer montagne mort musical musique oblivion patch photoshop php piwigo provence qt ruine rêve sexy site web skins tomb raider trackmania ultramon united ville visual voiture windows étranger

Copyright © 2019 StrangePlanet » Blog.

Omega WordPress Theme by ThemeHall

  • Accueil
  • Blog
  • Galerie
  • Projets
  • À-propos