Quand vous développez (en Ruby, entre autres), vous écrivez des tests, n'est-ce pas ? Carrément en TDD ou au moins pour assurer la non-régression, j'espère. Le problème est : comment être sûr que tout votre code est bien testé ? Que vous n'avez pas un peu zappé d'écrire de tests pour telle méthode ou telle classe ?
La réponse s'appelle la couverture de code (“code coverage”, en anglais). Ça consiste à calculer le pourcentage de votre code qui est couvert par des tests. La chance, c'est qu'en Ruby, si votre code est hébergé sur GitHub, il existe une solution en SaaS qui fait ça toute seule : Coveralls !
Inscription
Il faut en premier lieu s'inscrire sur Coveralls.io, mais grâce à l'authentification GitHub, c'est fait en 2 clics.
Coveralls vous demandera ensuite sur quels repositories vous voulez l'activer avec des petits boutons on/off très intuitifs (comme souvent, c'est gratuit pour les projets open-source, payant pour les projets privés) :
Installation
Comme d'habitude, c'est super simple, il y a une gem à ajouter à votre fichier Gemfile
:
gem 'coveralls', require: false
Puis, il suffit de faire un bundle install
pour l'installer.
Enfin, il faut dire à notre suite de tests d'utiliser la gem, en ajoutant les lignes suivantes au fichier de config de votre suite de tests (moi j'utilise RSpec donc c'est spec/spec_helper.rb
, mais je vous laisse adapter à votre suite de test : Coveralls est compatible entre-autres avec RSpec, Cucumber, Test::Unit, …) :
require 'coveralls'
Coveralls.wear!
Ou, pour une application Rails :
require 'coveralls'
Coveralls.wear!('rails')
Configuration
Si vous utilisez Travis, c'est très simple : il n'y a rien de plus à faire ! Dès votre prochain push, Travis devrait donc tester votre build, et envoyer le rapport à Coveralls, qui calculera en détail la couverture de votre code.
Si vous utilisez Semaphore ou CircleCI, ça marche aussi, mais je n'ai pas testé : je vous laisse vous reporter à la documentation.
Si vous n'utilisez pas de service d'intégration continue, je vous conseille de vous y mettre rapidement, c'est de la tuerie. Moi j'adore Travis, et en plus, il est gratuit pour les projets open-source. Sinon, pour Coveralls, vous pouvez le configurer (en ajoutant une variable repo_token
à un fichier .coveralls.yml
) pour pouvoir faire des analyse de couverture à la main, avec un simple bundle exec coveralls push
.
Résultat
Sur le site de Coveralls, vous pouvez donc voir un résumé de votre projet, build par build :
Pour chaque build, un résumé fichier par fichier :
Et enfin, le truc le plus utile et productif : pour chaque fichier, le détail de couverture ligne par ligne :
Là, par exemple, on voit que je n'ai pas écris de test pour la méthode download_best_subtitle
, ce que je peux donc m'empresser d'aller faire.
Bonus : le badge GitHub
On peut même récupérer le code pour insérer un badge dans notre README, pour avoir la classe américaine sur GitHub :
Sources
- Le site de Coveralls
- La doc Coveralls pour Ruby