Le bagot du jour de l'an ou l'assert laxe

le 8 janvier 2015, par Bruno Thomas

Le 2 janvier est propice à la chasse au bagot : il est fréquent de rentrer encore un peu barbouillé des fêtes de fin d'années et d'être accueilli par une intégration continue rouge. Tests qui ne fonctionnent qu'en année bissextile, année codée en dur, numéro de mois qui va de 0 à 11, toutes les raisons sont bonnes.

Cela m'est arrivé une nouvelle fois vendredi dernier. En regardant l'historique des réussites/échecs des tests d'acceptance, j'en vois un qui bagote beaucoup depuis le 1er janvier. Il se trouve que ce test est déjà repéré dans notre liste de bagots non résolus, mais la fréquence m'interpelle.

C'est le test d'un export de statistique en fichier CSV. Sélénium entre une date début et une date fin dans les champs d'un formulaire et clique sur le bouton exporter. Je suis le fil du code et j'arrive ici :

OK, la ligne attendue (la variable expected_line_dict ci-dessus) est la suivante :

{'event': 'login', 'user': 'foo', 'parametre_metier': 4}

et le fichier contient :

date,queue,event,user,parametre_metier
...
02-01-2015T02:12:43,,login,foo,3
...

Donc d'après le code, je prends chaque ligne du fichier. Si toutes les valeurs attendues ('login', 'foo', 4) sont contenues quelque part dans une ligne du fichier CSV alors le test de cette ligne est vert. WTF ??

Nous avions passé le parametre_metier de 4 à 3 pour tous les tests d'acceptance il y a quelques mois. La modification de ce paramètre n'a donc pas été reportée dans les valeurs attendues. Ce test devrait être rouge ! Mais qu'est-ce que... Ouéééé !! Comme il y a un 4 dans 2014 le test était toujours vert l'année dernière, mais pour 2015, il suffit qu'il n'y ait pas de 4 dans la date ou l'heure et il passe rouge.

Morale de l'histoire, attention aux assertions trop laxes, cela peut donner des résultats étonnants. Et encore c'est un euphémisme, car on le voit ici, c'est de la perte de temps, et aussi de confiance dans le harnais de test. Après avoir ajouté des tests unitaires montrant les deux erreurs (pas de vérification par champ et inclusion de valeur) j'ai relancé les tests d'acceptance : plusieurs d'entre eux sont passés rouge ; Toujours rouge ;)

Maintenant, il ne nous reste plus qu'à les faire passer au vert ; Toujours :)

Astuce - laisser nginx répondre robots.txt

le 7 janvier 2015, par Jean-Philippe Caruana

Sur le service sur lequel je travaille, j'ai observé de nombreuses erreurs 500 suite à des tentatives du Google Bot de trouver le fichier /robots.txt. Voici par exemple une log d'erreur de nginx :

Git - le message systématique qui agace

le 19 décembre 2014, par Jean-Philippe Caruana

A chaque git fetch ou git pull --rebase ou encore git merge branche, j'avais un message agaçant, même quand il n'y avait rien à faire (branche à jour). Par exemple :

Migrer un blog de Wordpress vers Jekyll

le 11 décembre 2014, par Jean-Philippe Caruana

Suite à la migration de notre blog vers un jekyll hébergé chez github, je vous propose quelques explications sur le sujet. Dans cet article, nous verrons :

Barre Verte a migré

le 5 décembre 2014, par Jean-Philippe Caruana

Nous venons de terminer la migration de Barre Verte : auparavant, nous nous hébergions nous-mêmes sous Wordpress chez Gandi, désormais, nous utilisons Jekyll hébergé (gratuitement) par Github.

MongoDb le cluster qui bagote

le 11 octobre 2014, par Philippe Blayo

Mug MongoDB Un soir, un développeur lâche en partant : « MongoDb c’est de la merde. Leur réplication ça marche pas. Je parie qu’on a aussi le bug en prod. Pour un peu j’en jetterais ma tasse mongo par la fenêtre. »

Les héros du bagot

le 19 juin 2014, par Bruno Thomas

hudson_trends

Cela fait 6 ans que nous faisons des tests fonctionnels (ou d'acceptance). Tests FitNesse, GreenPepper, Concordion avec ou sans IHM (Selenium par ex). Une chose reste constante, c'est la difficulté de stabiliser ces tests. Les approches sur le sujet dans les conférences sont variées, mais l'énergie mise dans la maintenance de ces tests semble toujours importante.

Le défi est double : avoir des tests qui s'exécutent rapidement, et dont la stabilité permet de détecter de manière certaine les régressions fonctionnelles. Ce que nous constatons sur les 4 projets qui ont mis en oeuvre des tests d'acceptance, c'est que le non-déterminisme de la plupart des tests provoque des bagotements (flaky tests). Tant et si bien que nous avons donné un nom à ces défauts de déterminisme : les bagots. Le soucis avec ces bagots, c'est qu'ils empêchent de décider si un test est rouge pour une bonne raison (une régression), ou pour une mauvaise raison (typiquement une mauvaise séquence d'accès concurrents du test).

Ces tests sont "probabilistes" : lorsque l'ordonnanceur partage équitablement le temps entre les différentes unités de calculs (process, threads), le test est vert. Avec une machine lente ces tests sont plus fréquemment rouges. Une sélection inattendue de ses maigres ressources provoquerait le même comportement. Dans une équipe avec le même environnement de développement (garanti par l'utilisation d'une image en chroot), le développeur ayant la plus mauvaise machine a le plus de chance de reproduire les bagots : un événement reste trop longtemps dans un bus de données, un réplicant mongoDB "laggue" alors que nous allons y lire une valeur... le test est rouge.

Il existe une multitude de manière de reconnaître ces tests. Un fort "smell" est constituée par l'utilisation d'un sleep : nous sommes alors dans le monde du test probabiliste. Le test est rouge ? Passons l'attente de 1 à 5 secondes. Allez, 10 secondes pour être sûr. Ça ne vous dit rien ? On me dit Courage ? Non, jamais entendu parler : supprimer ces 5 lettres suivies d'un entier est souvent un "refactoring" qui aura des répercussions profondes.

Sur notre dernier projet, nous avons beaucoup de code javascript exécuté dans le navigateur. L'ergonomie en est largement améliorée, mais la gageure des tests d'acceptance est encore plus grande. Nous avons parfois passé plusieurs jours, plusieurs semaines avant de résoudre un bagot (et parfois même échoué). Alors pour les héros qui ont pris leur courage à deux mains, et ont stabilisé ces tests, nous allons vous raconter leurs histoires, des histoires de bagots.

Notes sur l'Agile Conférence 2014

le 28 mai 2014, par Bruno Thomas

Ça se passait les jeudi-vendredi 22 et 23 mai toujours au chalet de la porte jaune. Cette année, la conférence suivait au moins 2 fils. L'un explicite "le fil rouge", activité de médiation graphique omniprésente et l'autre en trame, avec une résonance entre la keynote de Régis Médina sur le produit lean et les sessions qui ont suivi.

L'après-XP pour du développement produit

Avis de non-responsabilité : pratiquant l'XP depuis 7 ans, en partie avec Antoine C, et travaillant avec David B, membre de l'équipe d'organisation les propos suivants sont éventuellement subjectifs ;)
Cette keynote était une bonne introduction, une synthèse construite autour de l'expérience de Régis parti de l'extreme programming pour faire du lean. Ce ne sont plus des pratiques lean (les liens ci-dessous) qui sont expliquées mais l'utilisation de ces pratiques au service d'un nouveau modèle de gestion du système de production logicielle. Le marché a changé, l'open source, les plate-formes de téléchargement (apple store, android store...), les éditeurs, mettent en compétition énormément d'acteurs. Pour sortir du lot, il faut créer un effet "whaoo!!".

Créer un chroot (part. 2) : se connecter

le 22 avril 2014, par Philippe Blayo

Dans un précédent billet, nous avons créé un linux de base. Son arborescence a maintenant besoin d'être rattachée à la machine sur laquelle elle va s'exécuter. Pour cela nous allons répliquer les pseudo-systèmes de fichier /dev /proc et /sys déjà présents sur la machine :

    • /proc contient les infos sur les processus en train de tourner
    • /sys contient des informations système sur comment créer les périphériques (numéros de séries...)
    • /dev contient les fichiers d'accès aux périphériques eux-même (recréés dynamiquement par udev à chaque redémarage à partir des infos de /sys)

Le fichier complet