Capybara et les tests d’acceptation

Capybara est un framework de test d’acceptation pour les applications web. Il se présente sous la forme d’une gem. C’est notamment l’un des outils qu’utilisent les développeurs de MH-Communication pour mettre en place le Golden Master Testing. Grâce à cette gem, il est possible de simuler l’interaction d’un utilisateur réel avec l’application.

Capybara fonctionne avec différents frameworks de test pour Ruby on Rails : Test::Unit, RSpec, Cucumber, MiniTest::Spec, … Personnellement, Je l’ai essayé avec Test::Unit. Par défaut, Capybara utilise le driver rack-test, mais il est conseillé d’utiliser Selenium qui supporte le JavaScript.

Une fois installé, Capybara permet de naviguer sur l’application de façon automatique, et ainsi d’effectuer des tests sur les pages affichées.

Quelques méthodes utiles :

L’ensemble des méthodes utilisables avec Capybara est présenté sur le github de Capybara : Github

Les TDD en toute agilité, par Julien et Pierre-Olivier – Printemps agile 2015

Notre équipe a été invitée à faire une présentation durant ce Printemps agile 2015. Julien et Pierre-Olivier se sont lancés et ont proposé d’aborder la technique du TDD, ou Test Driven Development (développement piloté par les tests en français), technique que l’équipe pratique quotidiennement.

Juste après avoir (peu) mangé, Pierre-Olivier et Julien ont donc présenté la technique du développement piloté par les tests. Ils ont montré l’intérêt de cette technique et ont, à travers un live-coding, expliqué la façon dont nous la pratiquons au sein de l’équipe.

Les TDD en toute agilité
Pierre-Olivier et Julien nous présentent le contenu de leur présentation.

La qualité des questions posées à la fin de la présentation a montré l’intérêt porté par l’assistance à cette présentation. Les questions ont permis d’approfondir quelques points abordés succinctement et d’élargir le dialogue aux tests d’intégration, sujet qui n’avait pas été développé durant la présentation, et au développement de tests automatiques pour des applications existantes non testées. Ne pratiquant pas les tests d’intégration, Pierre-Olivier et Julien ont laissé la parole à Frédéric, présent dans l’assemblée, qui a évoqué les deux solutions Selenium et Nagios. La personne s’étant questionnée sur la refonte d’applications non testées a été invitée à suivre la présentation de Mathieu Sadouni et Pierre-Emmanuel Fringant intitulée « Sécuriser une refonte avec le Golden Master Testing » se déroulant juste à la suite de celle-ci.

Les slides de la présentation « Les TDD en toute agilité » sont disponibles à l’adresse : http://slide.julien-anne.fr/les-tdd-en-toute-agilite

Rails : quelques Gem utiles

Awesome Print

Awesome Print est une gem à installer en développement. Elle remplace agréablement les logger.fatal en  affichant les objets de façon indentée et colorée.

Cocoon

Cocoon prend en charge les relations has_many (nested attributes) dans les formulaires (standards, SimpleForm et FormTastic).

Gmaps 4 rails

Donne la possibilité de créer des cartes Google Maps personnalisées.

High Voltage

High Voltage est une gem qui simplifie la gestion des pages statiques.

Letter Opener

Letter Opener est une gem à installer en développement. Elle permet de prévisualiser les emails directement dans le navigateur.

Quiet Assets

Cette gem permet de cacher les innombrables lignes de chargement des assets dans la console et dans les logs.

Rest Client

Cette gem permet de faire des requêtes HTTP simplement.

Simple Form

La gem Simple Form simplifie l’écriture des formulaires grâce à une syntaxe plus légère.

Will Paginate

Will_paginate permet de créer une pagination très facilement.

source : lewagon.org

Mysql2::Error: Incorrect string value

En Ruby on Rails, lorsque vous importez des données dans une base de données MySQL, via un fichier CSV par exemple, il peut arriver que vous rencontriez l’erreur Mysql2::Error: Incorrect string value. Cela peut être dû au fait que votre fichier CSV est encodé en UTF-8 alors que l’interclassement de la base de données est en Latin par défaut.

Pour changer l’interclassement d’une table de la base de données, ou directement d’un champ, il faut saisir  les requêtes :

Remplacer Test::Unit par RSpec ?

Test::Unit étant le framework de test pour Ruby on Rails installé par défaut sur un projet Ruby on Rails, c’est celui que nous utilisons au sein de l’équipe pour faire du TDD. Beaucoup de développeurs lui préfèrent cependant RSpec. Je me suis donc penché dessus lors d’une session de veille afin de le comparer à Test::Unit.

L’installation de RSpec se fait via une gem, de façon classique. Il faut ensuite générer les fichiers de test qui seront stockés dans un répertoire spec, à la racine du projet (comparable au répertoire test utilisé par Test::Unit). Chaque fichier de test sera ensuite généré automatiquement lorsqu’on générera un scaffold, un modèle ou un contrôleur.

Après avoir lu les tests générés par RSpec et en avoir écrit quelques-uns, il me semble que RSpec propose sensiblement les mêmes fonctionnalités que Test::Unit, les différences étant principalement sémantiques.

Test écrit avec Test::Unit :

Le même test écrit avec RSpec :

À noter que par défaut, RSpec n’utilise pas de système de fixtures. Il est cependant conseiller de le coupler à Factory_Girl.

On remarque que la syntaxe de RSpec est sans doute plus verbeuse que celle de Test::Unit. En lisant le test, on comprend tout de suite ce que fait (ou doit faire) le code de la méthode testée. Les mots-clés de RSpec (« describe », « context », « it », …) permettent de faire des phrases qui rendent le code lisible même pour un public non développeur. On dit souvent que les tests d’une application remplacent la documentation. C’est encore plus le cas si on utilise RSpec.

N’ayant pas vu de différence fondamentale entre RSpec et Test::Unit, nous continuons à utiliser Test::Unit que nous maitrisons bien. Cependant, il serait intéressant de prendre le temps de développer un projet en utilisant les deux frameworks de test en parallèle, pour pousser plus loin la comparaison.

Lectures complémentaires :

Paperclip et compression d’images

Paperclip est une gem pour Ruby on Rails qui simplifie la gestion de l’upload de fichiers. Il est notamment intéressant pour l’upload d’images et la création de plusieurs versions de ces images dans des dimensions différentes.

Installation de Paperclip

Avant d’utiliser Paperclip, il faut s’assurer qu’ImageMagick est installé sur l’ordinateur.

Ensuite, on peut ajouter la gem à notre gemfile :

Utilisation de Paperclip

Pour ajouter un champ de type « Paperclip » (ou attachment) à un modèle existant, il faut faire une migration.

Cette migration ajoutera en base de données les champs nécessaires  à la gestion de l’image, à savoir image_file_name, image_content_type, image_file_size et image_updated_at.

On peut ensuite modifier le modèle pour spécifier les types de fichiers acceptés et dimensions souhaitées.

L’attribut styles permet de réaliser des post-traitement sur les fichiers uploadés. Le post-traitement par défaut est « thumbnails », qui crée les miniatures dans les dimensions spécifiées. Ici, trois miniatures vont être générées avec des largeurs (ou hauteur) de 1000px, 500px et 300px.

Le ‘>’ des styles « large » et « medium » va générer une nouvelle image dont la largeur et la hauteur ne dépasseront pas les valeurs spécifiées tout en gardant le ratio de l’image de base, tandis que le ‘#’ du style « thumb » va croper une image carrée de 300×300 à partir de l’image de base. Les différents traitements « thumbnail » possibles sont expliqués sur la documentation de ImageMagick.

Dans l’exemple ci-dessus, le validates_attachment_content_type renseigne le type de fichier accepté. Ici, tous les fichiers image le sont. On pourrait limiter aux fichiers JPEG en écrivant :

Beaucoup d’autres types de validation sont possibles, par exemple la présence du fichier, la taille maximum du fichier, etc…

Le formulaire d’upload à utiliser avec Paperclip est un formulaire classique :

Il n’y a aucun traitement à faire ensuite au niveau du traitement du formulaire. Il faut juste s’assurer que l’attribut « image » est présent dans la liste blanches des paramètres autorisés :

L’affichage des images dans les vues se fait simplement :

Compression d’images

Pour réduire les temps de chargement des pages web, les images doivent être optimisées. Une solution est de les compresser avant de les envoyer sur le serveur (« enregistrer pour le web » sous Photoshop). Seulement, on ne contrôle pas les fichiers qui sont envoyés sur le serveur par les utilisateurs de nos sites. La meilleure solution consiste donc à compresser les images une fois uploadées sur le serveur. Associée à Paperclip, La gem paperclip-compression s’occupe de cela pour nous.

L’usage basique de cette gem est le suivant :

Liens complémentaires :

Atom, un concurrent sérieux à Sublime Text ?

Atom est un éditeur de code concurrent de Sublime Text et Brackets sorti en 2014 et développé par Github. Utilisateurs quotidiens de Sublime Text depuis plusieurs années, il est temps pour nous d’essayer ce nouveau venu.

logo-3f63f8265b387a01752f4dc7e90ad48bL’éditeur est basé sur le navigateur Chromium, gratuit, libre et Open-Source ce qui permet à chacun d’étendre ses fonctionnalités.

Comme pour Sublime Text, une multitude de packages est disponible pour Atom. Un grand nombre de packages est d’ailleurs installé par défaut dans le noyau Atom (autosave, dev-live-reload, …). Chacun peut selon son utilisation les activer ou désactiver individuellement. Il est possible aussi d’en développer soi-même.

Il est également possible de définir ses snippets pour coder plus efficacement.

Quelques packages intéressants

Je me suis concentré à retrouver l’équivalent des packages que j’utilise sur Sublime Text. Voici quelques exemple :

  • autosave est un package du « core » qui sauvegarde automatiquement un fichier lorsqu’il perd le focus. Il suffit de l’activer pour le faire fonctionner.
  • save-session permet de réouvrir le projet et les onglets ouverts lors de la prochaine session.
  • autocomplete-plus permet d’obtenir une autocomplétion directement lors de la saisie des mots-clés, comme le fait Sublime Text (et non plus en tapant ctrl+tab).
  • file-icons améliore l’interface d’Atom en affichant de jolies icônes à côté des noms de fichiers et sur les onglets qui indiquent le type de fichier.
  • atom-color-highlight surligne un code couleur avec la couleur correspondant à ce code.

Exemple de Snippets

Ayant développé nos propres snippets sur Sublime Text, je me suis penché sur l’écriture de snippets sur Atom.

Pour afficher la liste des snippets utilisables, il suffit d’utiliser le raccourci clavier alt+shift+S. Pour ajouter un snippet, il faut éditer le fichier ~/.atom/snippets.cson. Il se structure de la façon suivante :

Atom est un éditeur de code qui semble prometteur, qui pourra peut-être à terme remplacer Sublime Text sur nos postes. L’avenir nous le dira.

Sécuriser une refonte avec le Golden Master Testing – Printemps Agile 2015

Matthieu Sadouni et Pierre-Emmanuel Fringant nous ont présenté le principe du Golden Master Testing lors d’une présentation du Printemps agile 2015.

La problématique est la suivante : Comment assurer la refonte d’une application non testée (legacy code) réalisée par une autre équipe tout en assurant la maintenance de l’existant ?

L’idée du Golden Master est de vérifier que pour un ensemble de paramètres donnés en entrée, la sortie de l’application ne varie pas. L’application est alors vue comme une boite noire. L’état initial de la sortie  est appelé Golden Master. Une fois celui-ci défini, on peut  développer de nouvelles fonctionnalités ou factoriser le code existant sans souci : si la sortie reste identique au Golden Master, c’est qu’aucun effet de bord n’a été constaté. Il peut arriver que la sortie soit différente du Golden Master mais qu’elle soit tout de même valide (si l’application de base contient des bugs par exemple). Dans ce cas, la nouvelle sortie devient le Golden Master pour la suite du développement.

Pour mettre en place le Golden Master Testing, Pierre-Emmanuel et Matthieu utilisent rspec et capybara. Tout leur processus est expliqué sur github : https://github.com/mhcommunication/golden-master

Créer un raccourci SSH

Pour se connecter à un serveur via SSH, il faut indiquer un nom d’utilisateur et l’IP du serveur.

Cela peut être fastidieux lorsqu’on a à se connecter à différents serveurs plusieurs fois par jour. C’est pourquoi il peut être intéressant de créer des raccourcis. Deux méthodes existent : créer un alias pour le shell, ou créer un raccourci SSH.

1. Créer un alias pour le shell

Pour cela, vous devez vous placer dans un fichier de config de votre shell (~/.bashrc, ~/.bash_aliases, ~/.zshrc, …) et écrire :

Une fois le fichier de configuration « rechargé » (source ~/.bash_aliases, ou redémarrage du shell), vous pouvez utiliser l’alias mon-alias pour vous connecter au serveur.

2. Utiliser ~/.ssh/config

Une autre solution est de créer un raccourci SSH. Elle me parait meilleure car elle permet d’utiliser le raccourci dans plus de situations.
Pour cela, il faut éditer le fichier ~/.ssh/config. Ce fichier doit respecter une structure définie :

Une fois votre configuration définie, vous pouvez vous connecter au serveur en tapant :

Cette méthode est vraiment intéressante lorsque vous souhaitez par exemple copier un fichier local sur le serveur, ou cloner un projet git :

À noter que les deux méthodes peuvent être utilisées simultanément. Par exemple, je me connecte aux serveurs avec mes alias Shell et utilise mes raccourcis SSH pour copier des fichiers sur les serveurs ou cloner des projets git présents sur les serveurs.

Source : scotch.io

Sublime Text : créer un snippet

Un snippet est un bout de code qui permet d’insérer du texte grâce à un mot clé. Par exemple, dans Sublime Text, lorsqu’on saisit « lorem » puis qu’on appuie sur la touche Tab, un paragraphe « Lorem Ipsum » est inséré dans le fichier.

Posséder ses propres snippets peut être intéressant pour gagner en productivité. Un exemple simple en Ruby on Rails : on veut obtenir la méthode link_to en saisissant « lt ».

Pour cela, dans Sublime, il faut créer un nouveau snippet (Tools > Developer > New Snippet…). On obtient ainsi un exemple XML de snippet que l’on peut modifier.

  • La balise <content> doit contenir le texte à insérer.
  • La balise <tabTrigger> contient le mot-clé à saisir pour insérer le snippet.
  • La balise <scope> permet de limiter la visibilité du snippet à certains types de fichiers
  • On peut également ajouter une balise pour afficher une description lors de l’appel du snippet

Le CDATA permet de saisir des caractères spéciaux dans le contenu du fichier XML

Les mots label, url et title sont trois variables que l’on modifiera à chaque fois. C’est pourquoi ils sont placés dans ${…}. Le ${1:label} met ainsi le mot « label » en surbrillance lorsque le snippet est inséré. Une fois modifié, on appuie sur Tab. Le mot url est alors mis en surbrillance, et ainsi de suite.

saisie d'un snippet

Une fois le snippet saisi, il faut l’enregistrer dans le répertoire User (Sublime Text3/Packages/User) avec l’extension .sublime-snippet. Il devient alors utilisable dans Sublime-Text. Il suffit de saisir « lt » puis d’appuyer sur Tab pour insérer un link_to.

Vous pouvez retrouver les snippets que nous utilisons sur Github : https://github.com/maattt/sublime-text3-config/tree/master/Packages/User/snippets.