Je teste donc je suis

Quand on travaille sur des gros projets, on a tendance à rajouter beaucoup de fonctions, de code, partout, à tout bout de champ. Il faut savoir prendre du recul, pour simplifier le code, et faire des choses simples et efficaces.

Dans le cadre de mon travail, l'équipe test a pas mal changé cet été, avec 2 nouveaux arrivants. Ca tombe bien, on a aussi récupéré des nouveaux projets à tester. C'est en les formant à nos méthodes, notre code, que j'ai repéré des améliorations à faire, et qu'ils ont fait des suggestions intéressantes.

Avec leur arrivée, une partie de ma charge de travail a pu diminuer un peu, me permettant de réflechir, de me poser des questions, de chercher des idées "innovantes" pour résoudre des problèmes mis de côté par manque de temps depuis des semaines (voire plus).

Mise en place en 3 clics

Bon, j'éxagère, il faut plus que 3 clics. L'utilisation d'un Gemfile et de la gem bundler permet de simplifier l'ensemble de la procédure.

Pour préparer un nouveau poste (suite à une embauche, une réinstallation, ou un nouveau serveur, il faut alors installer ruby, la gem bundler, récupérer le dépôt du code, puis lancer juste la commande bundle install. Et le tour est joué.

Pour aller plus loin : mise en place sur tous les serveurs de tests d'une routine vérifiant que la liste est à jour et conforme à ce qu'on attend, avec un

bundle update
gem cleanup

L'information, le nerf de la guerre

Plongés dans les tests, nous disposions de plusieurs documentations, avec des buts plus ou moins précis. Localisées à plusieurs endroits. Du coup, petit ménage d'été, pour les regrouper, classer, mettre à jour. Au final, on a gardé plusieurs documents, pour plusieurs rôles différents :

• Documentation du code : présente depuis le début, avec génération automatique par la gem ruby rdoc et un petit script ruby (basé sur des expressions régulières) pour lister les step_definitons. Basée évidemment sur les commentaires dans le code, qui sont eux mêmes le premier niveau d'explication.
• Documentation sur comment coder : quelques documents précis sur comment installer l'environnement, les conventions de codage, ou des points précis et complexe des tests.
• Documentation sur les produits : nous testons une demie douzaine de projets, plus ou moins liés les uns avec les autres. Pour pouvoir teter efficacement, il vaut mieux savoir comment le projet fonctionne, et dans l'idéal, connaître également les bugs les plus courants sur le projet.

Codes complexes et compliqués

Aujourd'hui, l'ensemble de nos codes testant les projets de la société représenter environ 11 000 lignes de codes (essentiellement en ruby, cucumber, shell)

Il y a 10 jours, j'ai regardé pour la première fois depuis des mois les résultats de flog sur le projet. Pour résumer, flog analyse le code source, compte combien de fois on effectue chaque "action", et s'ensuit une note de complexité pour chaque méthode, et pour l'ensemble.

Comme on peut classer, on voit immédiatement les fonctions les plus compliquées. Reste à savoir si la complexité est normale ou non. Après avoir lu pas mal d'articles sur le sujet, et testé moi même sur notre code, j'estime qu'une fonction avec un score supérieur à 50 doit être analysée, et éventuellement, modifiée.

Quelques chiffres

J'ai profité d'un "temps calme" au bureau pour bosser sur le sujet.

Avant :

7128.5: flog total
    15.6: flog/method average

   793.5: main#none
   236.1: main#launch_browser
   197.0: main#get_job_results
   138.0: Then#/^HTML (contain|don't contain) (.*)$/
   136.7: Then#/^I don't see errors$/
   134.8: FormatPage#format_is_present
   131.1: main#compare_stats
    90.7: Then#/^I click on the insocial expand$/
    81.4: main#stats_of_day

Après :

6166.2: flog total
    13.8: flog/method average

   827.4: main#none
   197.0: main#get_job_results
   168.0: main#launch_browser
   134.8: FormatPage#format_is_present
    90.7: Then#/^I click on the insocial expand$/
    90.3: main#compare_stats
    77.0: main#stats_of_day

On note plusieurs choses :

• La note globale a chuté (-14%).
• Cela fait mathématiquement baissé la moyenne par méthode.
• Certaines méthodes "complexes" ont bien baissé.
• D'autres ont augmenté : avec les pull request de mes collègues, rien d'aberrant. La note a donc baissé alors que dans le même temps, plus de 1 500 lignes de code ont été ajoutées / modifiées.
• Certaines méthodes, complexes, ont une note qui correspond à leur difficulté de compréhension.

Qu'est ce que j'ai changé ?

Rien de transcendant :

• Du code dupliqué a été "mis en commun" pour faciliter la maintenance.
• Des optimisations faciles : par exemple, dans une méthode utilisant beaucoup de données, j'ai remplacé l'utilisation d'un tableau par une copie du contenu d'une données. Passer de my_array['result']['report']['url'] à my_url quand c'est utilisé 7-8 fois, ça améliore la complexité et aussi la lisibilité et la maintenabilité.
• Des méthodes ont été découpées pour clarifier ce que le code faisait.

Et c'est conventionnel tout ça ?

En parralèle, j'ai mis à jour la gem rubocop. Cette gem permet de vérifier que toutes les conventions sont respectées. La liste des choses vérifiées s'est beaucoup étoffée depuis la dernière fois que j'avais mis à jour la gemme (de 0.18.1 à 0.27.1), et j'ai passé quelques heures à modifier notre code pour qu'il passe les nouvelles règles.

Sur le projet, nous avons désactivé 27 règles parmi les centaines présentes. Par exemple, nous désactivons la limite sur le calcul de complexité cyclomatique puisque nous utilisons flog.

Rubocop nous a aussi aidé sur la complexité : une nouvelle règle a fait remonté quelques variables non utilisés. Les supprimer à fait baisser les notes de flog.

Pour l'automatisation, un git-hooks lance un script shell :

• vérifiant le résultat de rubocop,
• vérifiant qu'il ne reste pas de trace d'un conflit dans les fichiers,
• vérifiant que tous les fichiers yaml sont syntaxiement juste (find . -name *.yml -exec yaml-lint {} \; pour les analyser, avec la gem yaml-lint)

KISS, et après

Le principe KISS (pour Keep it simple and stupid) est une façon de travailler qui incite à rester simple pour être efficace. Certains points cités plus hauts ne sont pas triviaux à mettre en place, mais permettent sur le long terme à limiter les risques, à garder facilement du code propre, compréhensible, et simple.

Ma todolist pour la suite ?

• Traquer le code dupliqué (j'en ai déjà repéré quelques morceaux, dont le nettoyage n'était pas possible dans le temps que j'avais),
• Supprimer le code mort et non utilisé.
• Continuer à documenter, ranger, classer.
• Refactoriser ce qui peut l'être et dont le code n'est pas amené à disparaître dans les prochains mois.

Il y a des années qui sont très bonnes, pleines de bonnes choses. Pour moi, la référence, c'était 2009 : je me suis marié, nous avons acheté notre appartement, changé de voiture, ma femme a trouvé un travail.

Il y a des années, où c'est moins bon, mais qui ne sont pas mauvaises.

Et après, il y a des années où la poisse s'acharne. Pour moi, cette année noire, c'est 2014. Pour résumer, sur les 250 jours de l'année déjà passés, ma famille a compté pas loin de 300 jours d'hospitalisation. A tout ceci s'ajoute le fait que j'habite loin de mes familles, et que la communication n'est pas toujours simple.

• Janvier 2014 : Décès de ma belle-mère. Même si elle n'était pas en super santé, cela a surpris tout le monde. Ma femme était effondrée. (Et j'étais pas beaucoup mieux)
• Janvier 2014 : Mon père subit des examens pour un problème cardiaque. Avec stents. Posés avec complications.
• Février 2014 : Ma filleule entre en urgence à l'hôpital, et est placée en coma artificiel le temps de faire les examens, pour éviter qu'elle souffre. Une petite fille de 5 mois passe donc 15 jours dans le coma.
• Mars 2014 : Fin du coma, difficile et longue adaptation. Elle est clairement traumatisée, elle a peur des gens habillés en gris, etc...
• Mars 2014 : Au boulot, j'ai l'impression que rien ne va. Je mets ça sur le compte de mes ennuis familiaux.
• Avril 2014 : Mon père gagne un double pontage, en "urgence", avec plus d'un mois d'avance sur la date prévue.
• Avril 2014 : Je continue de cloisonner entre boulot et perso, mettant tout mon stress sur le compte du personnel.
• Avril 2014 : Mon père gagne un nouveau pontage.
• Avril 2014 : J'explique la situation à mes chefs, qui commençaient à se demander pourquoi j'étais aussi sur les nerfs. On réalise que l'effectif du pole qualité n'est pas suffisant. Contre mon avis, on privilégie des solutions pratiques plutôt qu'une embauche.
• Avril 2014 : On ajoute une chirurgie exploratoire abdominale sur mon père.
• Mai 2014 : Amputation de la jambe pour mon père.
• Mai 2014 : Sudweb me donne une bouffée d'air.
• Juin 2014 : Je revois mon père pour la première fois de l'année. Il est dans un tel état que j'ai l'impression de lui dire adieu.
• Juillet 2014 : Lors d'une sortie entre collègues organisée par ma société, blessure de mon binôme. Je suis donc seul là où on ne suffisait pas à deux.
• Juillet 2014 : Nouvel opération de mon père, pour "fignoler" l'amputation.
• Juillet 2014 : On fait passer des entretiens pour embaucher du monde au pole qualité.
• Aout 2014 : Au boulot, on me propose une mutation. De Toulouse à Montpellier. (5 personnes à Toulouse, 40 à Montpellier)
• Aout 2014 : Vacances. Repos, pas d'internet (ou si peu). Je me repose, j'oublie tout.
• Aout 2014 : Ma femme est très fatiguée, malade.
• Aout 2014 : J'apprends qu'une de mes tantes va mieux : elle a eu un AVC avec complications, alors qu'elle avait déjà une santé fragile.
• Aout 2014 : Premier jour de boulot, lorsque je prends ma voiture, quelqu'un a laissé un mot pour s'excuser pour la bosse. Ma portière s'est faite enfoncer durant la nuit.
• Aout 2014 : Deuxième semaine de reprise : chute de mon fils de sa hauteur à plat dos, on fini aux urgences. Il ne pose plus son pied par terre, et ne peut donc plus marcher. Ils nous font surveiller les symptômes d'un traumatisme crânien.
• Aout 2014 : Mon fils ne marche toujours pas 2 jours après, passage chez le médecin. Qui nous dit de patienter, puis de passer une échographie du genou.
• Aout 2014 : Ma meilleure amie passe aux urgences suite à un problème de santé pendant ses vacances.
• Aout 2014 : Avec l'arrivée d'un nouveau testeur qui code des tests auto, je ressens d'autant plus le manque de code pour moi. En regardant en arrière, j'ai du coder en tout et pour tout 15 jours depuis janvier. (Le reste, c'est du test à la main, dont 75% au moins peut être automatisé)
• Aout 2014 : Ma meilleure amie retourne à l'hôpital pour quelques jours après son retour de vacances.
• Septembre 2014 : Échographie négative pour le genou de mon fils, retour aux urgences. Cette fois, on est fixé (10 jours après) : il ne pose pas le pied par terre parce qu'il a une fracture du tibia (Fracture en cheveu, compliquée à voir sur une radio). C'est parti pour un plâtre pendant 3 semaines.
• Septembre 2014 : Ma femme est toujours malade, mais on est maintenant sûrs : on va être parents une deuxième fois.

Quand je racontais un point particulier à quelqu'un, on me disait toujours "Courage, ça va passer". Quand je vois la liste, je comprends mieux pourquoi, deux semaines après mon retour de vacances, j'ai l'impression de passer à côté de ma vie depuis quelques mois.

• J'ai un travail, où je devrais faire mon métier. Pourtant, j'ai l'impression de ne pas faire mon métier.
• J'ai une famille, que je ne vois pas aussi souvent que je voudrais.
• J'ai un fils, et j'ai l'impression de ne pas le voir grandir.
• J'ai une vie, mais je ne sais pas où elle me mène.

Depuis quelques semaines, j'avais envie de changer d'air pour mon blog : voir de nouvelles technologies, d'avoir un blog plus professionnel.

J'ai pas mal fouillé, et je suis très tenté par Jekyll et Poole, qui permettent d'avoir facilement un site statique écrit en markdown. Le tout hébérgé par github.

Plusieurs objectifs à ce changement :

• Etre encore plus maître de mon outil de publication.
• Découvrir de nouvelles technologies.
• En profiter pour faire le ménage sur le blog.
• Remettre à plat la ligne éditoriale.

Sudweb, j'en avais parlé il y a 2 ans, en 2012. Cette année, ça se passait à Toulouse, j'y suis donc retourné. Le changement, c'est que j'y étais uniquement en tant que "spectateur".

Vendredi : des conférences et des papotages

Le vendredi, c'est le jour des conférences. Je ne les citerais pas toutes, mais certaines m'ont bien marqué :

• La culture d'entreprise, vu par Kevin Goldsmith. J'ai eu un peu du mal à tout suivre en anglais de bon matin, mais intéressant, et finalement, cette notion de culture est revenu dans beaucoup d'interventions.
• La sédimentation des données, par Samuel Huron
• Comment afficher simplement des données dans le temps, de façon que le présent compte plus que le passé. Hate de pouvoir tester ça sur l'affichage des résultats de tests.
• Un cours de dessin de croquis par Eva-Lotta Lamm
• Deux petites histoires sur pourquoi les commentaires dans le code sont importants
• Tu peux pas test, un concept pour tester. J'étais sceptique sur le programme, mais Vincent Van Steen a finalement réussi à me convaincre que cette méthode peut avoir un intérêt dans certains cas, pour gagner du temps et de l'argent.
• Une histoire de print qui finit en web, avec un joli livre responsive ; la dette technique ; les réponses aux stress... et plein d'autres sujets ont été abordés.

Comme toujours, la journée est chargée en contenu riches, intéressants, et chacun y trouve son compte. Les pauses sont là pour échanger sur les conférences, sur soi, son métier... je suis timide, j'ai surtout parler à des gens que je connaissais déjà.

Et pour finir la journée, une conférence débat animée par David Bruant et Pablo Pernot, qui a soulevé beaucoup de questions à base de "mais pourquoi je travaille comme ça", "comment changer l'avenir de la profession", ou encore "quand ça va pas, il faut le dire".

Toute la journée, Romain a réalisé des posters basés sur les contenus des conférences, en live. J'ai trouvé ça impressionnant (que ce soit l'esprit de synthèse ou la mise en page) Sur le débat, il a été bluffant. J'ai hâte de voir le résultats des posters dans les prochaines semaines ! Le soir, j'ai fait l'impasse sur la soirée communautaire pour rentrer m'occuper de mon fils, et me reposer avant le deuxième round du lendemain. Sudweb 2014 - Un grand bol d'air frais

Samedi : ateliers et échanges

Le samedi à Sudweb, c'est souvent compliqué : des ateliers sont préparés dans les 7-8 salles dispos, et chacun va là où il veut. Avec la règle des deux pieds : "Si ça te plait pas, tu pars, et tu vas voir ailleurs". Cette année, j'avais un coup de coeur pour un atelier prévu de longue date. Du coup, cela m'a empêché d'aller à un autre qui s'est créé et organisé dans la matinée. Et du coup, j'ai fini par faire une journée sans "technique" :

• Atelier Légo pour faire des métaphores, étape par étape. Très intéressant, parce que cela permet vraiment de faire passer des idées par construction en 3D. (Un peu comme le cours de croquis de la veille)
• Atelier DIY : Do it yourself, avec construction par équipe. Mon seul regret : nous n'avons pas eu le temps de finir le device lab à base de tablette que nous avions commencé. Mais clairement, je suis arrivé en regardant mon bureau d'une autre façon lundi matin.
• Un atelier de travail en groupe avec une kinésiologue, où on a aussi bien parlé acuponcture que de nos frustrations professionnelles.
• Et enfin, la rétrospective de sudweb. Avec toute l'équipe qui a organisé ça, pour pouvoir dire ce qui nous a plus, ce qui a moins plus, et ce qu'on pourrait faire d'encore meilleurs l'année prochaine.

Sudweb, et après

Rien à dire, j'ai passé 2 supers journées. Je pense que si je pouvais, je ne changerais pas grand chose : j'y étais allé pour avoir un grand bol d'air, entendre parler de quelques technos que je maîtrise pas forcément, et m'ouvrir l'esprit à d'autres choses. J'ai tout bon sur toute la ligne. Un grand coup de chapeau à l'équipe qui a organisé tout ça.

Et après ? Lundi, retour au bureau, à la réalité. Le coup de boost de voir autant de gens voulant travailler encore mieux (dans tous les sens du terme) pendant 2 jours m'a remonté le moral. Mardi, j'ai un bon coup de blues, et je me demande si on devrait pas organiser un sudweb chaque semaine.

Il ne reste qu'à attendre les vidéos des conférences pour pouvoir les partager avec les collègues et connaissances pour leur montrer :)

Comme beaucoup de gens, je travaille toujours sur plusieurs projets à la fois. Mon rôle principal est de créer et maintenir des tests fonctionnels automatiques.

Pour gérer tout cela, nous sommes 2 personnes. Mais nous avons aussi des tests manuels à faire avant chaque mise en production de chaque projet.

Quelques chiffres

• 6 serveurs jenkins : 3 linux, 3 windows. (Uniquement pour les tests fonctionnels)
• 1 700 scenarios cucumber joués quotidiennement. (soit plus de 20 heures chaque jour)
• près de 300 jobs jenkins pour les ranger
• 7 produits principaux, à tester sur 1 à 3 navigateurs + mobile

Cela donne le tournis. Plus le temps passe, plus j'ai besoin d'avoir un affichage synthétique pour savoir si mes tests sont passés ou non.

J'avais dans le passé créer un petit plugin pour afficher mes résultats. Mais chaque projet est légèrement différent, demande des réglages différents, et j'arrivais aux limites de cet affichage. J'avais un écran par projet, soit 7 écrans de contrôle, que j'aurais voulu avoir toujours sous la main.

Plugin jenkins

J'ai donc regardé sur jenkins s'il existait des plugins permettant de lister les résultats au format json. Je n'ai rien trouvé de concluant, j'ai donc codé un petit plugin pour avoir un fichier jsonp qui liste tous les jobs, et pour chacun : * son statut courant, * les stats du dernier résultat, * l'avancement s'il est en cours... Vous pouvez trouver le code sur le dépôt github.

Console en javascript

Une fois le json obtenu, il restait à le traiter. L'avantage est de pouvoir le faire en javascript, ce qui permet à chacun de gérer ensuite l'avantage à sa sauce. J'ai fait un écran de contrôle pour l'ensemble des projets que je gère.

Et j'ai filé les clefs à une équipe sur un projet, qui a modifié l'écran pour avoir seulement les tests fonctionnels de son projet, et a ajouté les tests unitaires sur le même écran. Et voilà ce que ça donne :

• On peut séparer les jobs dans les différents projets via des expressions régulières.
• Pour l'un des projets, très conséquents, j'ai même séparé par navigateur.
• On voit bien les tests KO pour chaque job. (en rouge)
• Les jobs désactivés ou n'ayant pas de résultats sont gris.
• Les jobs qui sont en cours d'exécution sont en bleu, avec une barre d'avancement sur leur durée estimée.
• Les jobs qui seront lancés quand il y aura une place pour eux ont une pastille jaune.