• Uber et la RH

Le récit d'une ex-employée de chez Uber

• Ruby Debugging Magic Cheat Sheet

Les techniques de deboggage utilisées par Richard Schneeman (@schneems)

---

L'importance des tests, ce qu'il faut tester et comment s'y prendre.

Actus

On enregistre quelques épisodes à l’avance, donc on a toujours un décalage sur l’actu. Probleme de RH chez Uber, on va laisser mûrir la chose pour en reparler dans un episode sur l’éthique.

Le lendemain de l’enregistrement de l’épisode sur le debug, pleins de liens sont sortis dans les différentes newsletter ruby, ainsi qu’un blogpost de R. Scheemans très complet. Dommage.

On se pose les questions sur le format des actus, pensez vous qu’on devrait supprimer, remplacer, reprendre de l’actu avec du recul ?

Sujet du jour : les tests

Celine : découverte des tests sur une app existante en me cassant les dents parce que je ne savais pas ou commencer. Quoi tester ? Quel niveau de tests attendu (unitaire, acceptation) ? Confrontation directe avec la syntaxe, sans savoir si c’était les tests qui ne fonctionnaient pas ou la manière de les écrire qui posait problème.

Ronan : Faire des test a posteriori c’est pas ce qu’il y a de plus facile.

Guirec : Technique de BDD (Behavior Driven Development). Tu commences par faire un test de haut niveau (acceptation) qui simule le comportement de l’utilisateur (click sur les liens, remplir les formulaires, valider, voir une confirmation, etc.). Le test échoue forcément car l’implémentation est à faire. Au fur et a mesure du développement je rafine les tests avec des tests unitaires sur les actions dans le controllers par exemple, puis faire le changement minimal pour que le test passer et continuer sur les recommandations indiquées par le test de haut niveau pour implémenter ce qu’il reste à faire.

Ronan : c’est ce que j’appelle la grande boucle et la petit boucle. BDD = grande boucle, mais pour la réalisé on passe son temps dans des petites boucles ou on réalise les tests unitaires pour implémenter les étapes de la grande boucle, et on alterne entre les deux. Les rares fois ou j’ai été amené à faire des tests dans une app existence, j’ai pris comme point d’entrée les tests d’acceptation, c’est plus simple. Pyramide des tests : les tests de haut niveau sont au sommet et ceux de bas niveau sont la base de la pyramide. Et il y a beaucoup plus de test de bas niveau que de haut niveau. La question est du coup, est-ce qu’on traite tous les cas de figure à haut niveau.

Loic : c’est vrai que bien souvent, les tests d’acceptation ne sont pas aussi exhaustifs pour une raison simple aussi : ils coutent “très cher” à implémenter, ils sont longs à exécuter, à configurer sur les différents environnements de dev et de test/ci. Ce sont les tests que j’aime le plus pourtant. Donc par obligations d’économie de temps (un déploiement continu l’est-il vraiment avec une suite de tests qui dure 2h ?). C’est une des raison on a tendance à multiplier les tests de base niveau et considérer les tests de haut niveau comme un filet de sécurité.

Ronan, Guirec : C’est ce qu’on appelle le happy-path

Celine : Idem, j’ai donc pris le pas de commencer par ce happypath dans mes tests. Et à chaque fois que j’avais des validations a test, faire un test unitaire. J’étais plus à l’aise pour écrire les tests d’acceptation que les tests unitaire parce que je ne savais pas jusqu’à quel degré aller.

Loic : Qu’est-ce qui t’as amené à te dire je vais écrire des test.

Celine : Tout simple, j’étais unique développeuse dans ma startup, et à chaque fois que je rajoutais une feature, je serrai les fesses par peur que Áa casse tout, et je testais à la main le reste de l’application pour vérifier. Et à un moment, j’en ai eu marre de tout faire manuellement. Perte de temps énorme et stress incroyable, d’ou la recherche automatisation pour garder tout cela maintenable.

Loic : Quand vous êtes vous dit que c’était important de faire des test.

Guirec : J’en fais depuis très longtemps. Faire des tests automatisés, ça n’empÊche pas d’en faire à la main à la fin, mais l’automatisation permet de gagner du temps.

Ronan : je me souviens du moment ou j’ai réalisé l’intéret de faire des tests en TDD par rapport aux tests classiques. Je faisais souvent des tests a posteriori, et le grand intéret de faire l’inverse c’est que l’architecture de l’app est conduite par la la structuration en test et en devient plus robuste. Le filet de sécurité induit par les tests devient un “effet secondaire”.

Celine : Ce que j’ai apprécié quand j’ai commencé le TDD, c’est l’intentionalité qu’il y avait derriere. J’écrivais mes tests et en relisant j’avais exactement ce que je voulais que mon programme fasse.

Ronan: C’est le principe du test comme source de documentation là. Est-ce que certain utilisent des choses comme Cucumber ?

Guirec : je l’ai déja beacoup essayé, mais je me suis rendu compte c’était très long à gérer, beaucoup de répétitions de code et c’est difficile de faire lire les test cucumber aux clients de tout manière. Je suis content de rester juste avec ruby et pas de pseudo syntaxe.

Loic : Moi sur le TDD j’ai pas le sentiment inverse. J’en fais lorsque je suis exactement ce que je veux, sur des choses qui ont déjà un peu de maturité, sur des ajouts de fonctionnalité. Par contre quand je débute une app, j’aime bien d’abord coder avant de faire mon test, car j’ai plus l’impression que le code me dirige la ou je veux aller plutôt que les tests. Des fois j’ai l’impression que le TDD bride ma créativité. Vous avez parfois cette impression aussi ?

Ronan : Un ptit peu, moi le terme que j’utilise pour identifier ce que je ne connais pas assez ou ce que je dois étudier ou manipuler : un spike. Par contre au terme de la spike : j’efface tout parce que sinon tu vas être influencé. On parle de code à balle traçante, une cartouche sur trois c’ets juste pour faire de la lumière, comme ça on se repère vers la ou on veut aller. On s’oblige a effacer son code pour repartir dans la bonne direction. Parfois c’est un peu hypocrite, on efface, mais on se souvient très bien de comment on a fait et comme par hasard les tests qu’on va écrire vont suivre la meme direction.

** Ce transcript n’est pas complet et n’a pas été relu. Nous le publions toute fois tel quel, et si tu te sens de nous aider à le compléter et à le corriger, n’hésite pas à nous contacter et à proposer une fusiodemande ! **

---

Découvertes des invités

• Guirec Corbel

La musique Québécoise, ce n'est pas seulement Céline Dion ! – Violett Pi

• Sylvain Abélard

Compétition de "démo" de la scène japonaise. – Tokyo Demo Fest

Démo "non conventionelle" réalisée à partir d'un projecteur au laser. – Vainqueur du Tokyo demo fest 2017

• Ronan Limon Duparcmeur

Duncan donne des astuces de peintures sur figurines – Peinture de figurines sur warhammerTV

Quel séquence de spec provoque une erreur – Rspec Bisect

• Loïc Boutet

Utilisation du broker ZeroMQ pour mettre en place une architecture microservice en ruby – ZeroMQ

Construire des application ruby en toute confiance (beta) – Effective testing with Rspec3

• Céline Martinet Sanchez

appliquer un nouveau commit dans un autre – git commit --amend

rechercher d'un commit dans lequel un bug a été introduit – git bisect