J’ai été invité par Fleur Saillofest à speaker dans le meetup Beyond Scrum Mastering. Très rapidement, une trame intéressante a émergé lors de nos échanges : celle de reconnaître des problèmes au sein de l’équipe et y associer certaines pratiques tech qui pourraient aider.

Observer ce qu’il se passe dans l’équipe, entendre les râlements, les plaintes, noter les douleurs, c’est à la portée de tout le monde. J’ai pris un fil rouge avec des problèmes qu’une équipe peut rencontrer à diverses étapes de la conception du produit pour introduire certaines pratiques techs. Autour du besoin, du code, des tests, de la livraison, de l’existant, etc.

Est-ce que ce sont les seules possibilités ? Non. Mon but n’est pas d’être exhaustif ni sur les problèmes ni sur les solutions et les pratiques. Mais plutôt d’entrevoir des possibilités, de donner des billes pour ensuite aller creuser plus en profondeur avec l’équipe. Je dépose quelques brides de réflexion dans cet article qui m’ont permis de créer mon talk (slides ici).

Collaborer sur le besoin

• Les refinements sont chiants.
• On se rend compte pendant le sprint que les besoins ne sont pas clairs. Les développeurs demandent au PO des spécifications hyper détaillées avant de commencer.
• Le PO change d’avis, on fait ce qu’il y a écrit dans la story mais il dit que ce n’était pas ça qu’il voulait.

Les premiers problèmes peuvent arriver très tôt, dès l’expression du besoin, avant même d’être purement dans la tech, dans le code. On peut noter qu’il semble y avoir de l’incompréhension, qu’il y a probablement des choses implicites, des modèles mentaux différents. Que tous les membres de l’équipe ne sont pas vraiment impliqués.

Example Mapping

Une piste d’amélioration serait de faire collaborer toute l’équipe, ensemble, sur la rédaction du besoin. Je pense naturellement à l’Example Mapping. C’est un atelier qui réunit l’ensemble de l’équipe (PO, QA, Dev front/back). Le PO vient avec ses règles métiers et toute l’équipe œuvrera à créer des exemples précis pour chaque règle.

Tout le monde est impliqué, participe, et s’approprie le besoin. Les règles sont éclaircies, les exemples sont concrets et parlent à tous. L’implicite est rendu explicite, on sort ce qu’il y a de la tête du PO. Des questions peuvent émerger, avec des points à éclaircir avant de commencer le développement. On peut aussi trouver un découpage plus fin de la story.

Ce n’est plus à la seule charge du PO d’écrire un immense cahier des charges qui sera de toute façon probablement imparfait et jamais satisfaisant. Les développeurs ne restent pas passifs avec des pavés à avaler. On fait jouer l’intelligence collective en amont pour co-créer quelque chose de meilleur.

Collaborer sur le code / Git

• J’entends parler de branches, merge, commit, conflits, … Je suis perdu.
• C’est quoi ce git machin chose ?

Je dédierais un article pour vulgariser l’utilisation de git qu’en ont les développeurs. Je me limiterais à quelques lignes ici pour comprendre l’origine de certains problèmes. Git est un outil pour gérer les versions du code source.

Un développeur va créer un commit avec des changements ; c’est une copie à un instant T du code. Il va travailler sur une branche ; c’est un espace indépendant, avec ses propres copies.

Au bout d’un moment, lorsqu’il aura terminé, il va vouloir merge ; il veut réunir son travail réalisé sur sa branche (dans son espace indépendant) vers la branche principale (l’espace commun). Pour cela, il va ouvrir une Pull/Merge Request et demander à quelqu’un de faire de la revue de code ; une personne va relire toutes les modifications, pour approuver ou faire des retours.

Au moment de réunir, il peut y avoir des conflits ; dans son espace, il a modifié des zones qui ont aussi été modifiées sur l’espace commun. Il faudra résoudre ces problèmes afin de pouvoir rassembler les travaux. Qu’est-ce qu’on garde ? Qu’est-ce qui n’a plus de sens ? Qu’est-ce qu’il faut adapter ?

Plus longtemps on travaille sur une branche (dans son coin) et plus on attend pour réunir avec la branche principale (avec les autres), plus on augmente les problèmes. Par exemple, la quantité de changements et le temps qui s’allonge augmentent le risque de conflits et demandent une plus longue revue de code.

Collaborer sur le code / Revue de code

• J’en ai marre de devoir refaire plusieurs fois mon code après des aller-retours sur la code review.
• Les développeurs se plaignent que les revues de codes sont longues à faire et pas intéressantes.
• On attends longtemps avant qu’un autre développeur fasse la revue de code.

Ahhh, la revue de code, serait-ce le mal du siècle des développeurs après le mal de dos ? J’exagère un peu - j’avais envie d’écrire cette tournure humoristique - mais j’ai tout de même souvent observé des symptômes autour de la revue de code. Il faut dire aussi que c’est une pratique qui s’est très largement répandue dans les équipes. Pour autant, elle n’est pas toujours bien appliquée et elle vient avec son lot de contraintes.

Par nature, la revue de code via une Pull/Merge Request est asynchrone - la relecture arrivera un temps après la demande, qui nécessitera des changements qui seront faits un autre temps après, et ainsi de suite. Il y aura des changements de contexte, de la part du relecteur et de l’auteur. Et on sait que les changements de contexte nuisent à la productivité. On est interrompu, on sort constamment du flow (qui est long à trouver).

Le feedback est tardif. La revue est très souvent ouverte lorsque la story est entièrement terminée (rappel git : quand on veut réunir nos changements avec la branche principale). Les changements seront plus coûteux. La revue est parfois bâclée. Certains lisent rapidement en diagonal parce qu’ils n’ont pas le temps ou que ça ne les intéressent pas. D’autres vont pinailler, mais seulement sur des points insignifiants.

Ce peut être un goulot d’étranglement qui allonge la durée nécessaire pour livrer une fonctionnalité. C’est marquant lorsqu’il y a beaucoup de développeurs ou lorsque la responsabilité de la revue n’est donnée qu’à une poignée de personnes (par exemple, seul le lead/référent/manager).

Bien sûr, ce n’est pas tout noir. La revue de code peut être bien faite et a pour sa défense deux principaux bénéfices : c’est une occasion de donner du feedback pour améliorer le code et réduire les bugs, et c’est une façon de partager de la connaissance en lisant le code d’un autre.

Ok, on parle de feedback et d’apprentissage, comment pourrait-on faire mieux ? Avec un échange direct, temps réel. Avec de la mise en pratique plutôt que de la lecture passive. Avec du Pair Programming et du Mob Programming. On forme une équipe, on est ensemble, on peut faire mieux sur la collaboration. Les process de Pull/Merge Request ont davantage de sens dans le monde de l’open-source où les personnes ne se connaissent pas, ne travaillent pas ensemble, où il faut contrôler.

Pair Programming

Le Pair Programming est une pratique qui va permettre une réelle collaboration de deux personnes. On se met ensemble, sur un même problème, avec un seul ordinateur, en même temps. On échange pour trouver la solution et écrire du code. On échange pour s’améliorer en continu. Il y a une réflexion commune, deux cerveaux qui vont se challenger.

Ici, le feedback est immédiat. Je propose au plus tôt une autre approche de conception à mon pair. Je découvre une fonction plus performante au moment où j’écris ma ligne de code grâce au conseil de mon pair. On repère ce bug pendant qu’on développe la fonctionnalité ensemble. Maintenant tout de suite, pas après 5 jours de travail.

La transmission de connaissances, autant technique que fonctionnelle, est forte. Les deux développeurs travaillent ensemble au même moment. Ce meilleur pattern pour faire le traitement, je le découvre en direct voire je le mets en place moi-même. On donne en effet le clavier au non-sachant, afin de le faire pratiquer tout en le guidant. Ce scope fonctionnel, on l’aura co-créée, je le comprendrais, mon pair n’est plus le seul de l’équipe à pouvoir y travailler. C’est très efficace pour onboarder un nouvel arrivant aussi.

C’est en ça que la pair programming est puissant et ne divise pas l’efficacité par deux, il faut voir au-delà de “deux ressources qui travaillent sur un seul problème”.

Mob Programming

Le Mob Programming se trouve un cran après le Pair Programming : c’est tout un groupe qui va collaborer, en même temps, sur un seul et même problème, avec un seul ordinateur. L’intelligence collective va mener à une meilleure compréhension du problème et à une meilleure conception de la solution. Encore une fois, ce n’est pas simplement grouper un tas de personnes pour qu’elles regardent un seul développeur tout faire.

Le problème et les solutions sont discutés et challengés. Le groupe entier s’approprie le code et la fonctionnalité, tout le monde avance ensemble. On peut arriver à tacler des problèmes très complexes. Il y a une très forte transmission de connaissances et de compétences. C’est tout un groupe qui apprendra, en pratiquant, cette nouvelle technique ou cette fonctionnalité.

Note : on parle d’avoir un seul ordinateur, un seul clavier en pair et mob programming. C’est parfaitement compatible à distance avec des solutions de partage d’écran, de contrôle du clavier, de code collaboratif.

Collaborer sur le code / Conflits

• Le dev est terminé localement mais ça met beaucoup de temps à être livré car on a plein de conflits.
• La fonctionnalité marche sur ma branche mais maintenant que c’est mergé c’est cassé.

Intégration Continue

Parfois, quand on parle d’Intégration Continue, on entends Jenkins, gitlab-ci, pipelines, machine de builds, etc. Ce n’est pas ça, l’Intégration Continue. Tout ça, ce sont des outils. C’est du comment.

L’Intégration Continue, c’est d’abord un principe, une attitude. C’est rassembler très souvent les changements sur la branche principale (intégrer continuellement). On partage à tous nos changements plusieurs fois par jour ; plutôt que d’attendre de tout finir et de rassembler après 8 jours de travail intense.

Qu’est-ce que ça apporte ? Un cercle vertueux. On va faire de plus petites étapes pour rassembler plus souvent. On va faire de meilleurs tests automatisés pour s’assurer que tout est bon. Naturellement, on aura moins de conflits et de problèmes avec de petites modifications ayant une durée de vie courte.

Pair/Mob Programming

On l’a vu précédemment, le Pair et le Mob Programming permettent une réelle collaboration de plusieurs personnes. La communication est meilleure, puisqu’elle est immédiate et continue. Il y a moins de travaux simultanés en cours, puisque les développeurs se réunissent pour travailler sur le même sujet. Tout ça contribue à diminuer les risques de conflits et de problèmes de merge.

Écrire le code

• On a fait évolué l’écran recherche, et on a vu plus tard en prod que la logique métier du compte est complètement KO.
• On planifie de passer une après midi sur l’écriture de tests, on fait comment pour le prendre en compte dans la vélocité ?

Tests Unitaires

Il est important de clarifier ce que sont les tests unitaires et pourquoi on en écrit. Très simplement, un test unitaire est un test automatisé d’un scénario fonctionnel. C’est quelque chose qui vérifie que du code se comporte comme prévu, automatiquement, sans intervention humaine. C’est un programme qui lance un autre programme pour vérifier ce qu’il se passe dans différentes conditions.

On parle de comportement, de scénario fonctionnel : quand on écrit un test unitaire, on veut s’assurer de bien retranscrire le métier. C’est en ça qu’il est très important et utile pour le business, et que ce n’est pas seulement un élément technique.

Progressivement, on créé un filet de sécurité pour éviter certaines régressions. On diminue le risque d’avoir des bugs en production : on aura un feedback immédiat, pendant le développement, si une règle métier est cassée après un changement dans le code.

C’est au moment où l’on change le code que l’on sait si on altère involontairement le comportement, pas plusieurs jours après. Ce qui fait que les tests unitaires jouent un rôle essentiel au Refactoring, pour améliorer le code sereinement.

Test-Driven Development

Quand on écrit un test, une bonne pratique est de le faire au plus près du moment où l’on a écrit le code, et non pas bien après une fois que tout est terminé. Pourquoi ? Parce que c’est plus coûteux et difficile de le faire après ; le code n’ayant pas forcément été conçu pour être testable. Et parce qu’on passe à côté d’un bénéfice important : se faire guider par le test.

Et c’est la philosophie du Test-Driven Development. Ce n’est pas “écrire le test en premier” (c’est du comment). C’est se faire guider par les tests et par le métier. On définit le comportement que l’on veut obtenir (le test) puis on fait émerger la solution et on l’améliore.

On a une boucle de feedback extrêmement rapide. Quand on développe la solution, le test nous indique en quelques millisecondes si le comportement voulu est bien retranscrit.

À noter que l’écriture des tests unitaires et la pratique du TDD font partie intégrante du job de développeur et que ce n’est pas forcément plus long de tester. Au contraire, ça nous aide. C’est à faire dès qu’il y en a le besoin, en continu, il n’y a pas de permission à demander, de journées à dédier.

Livrer

• C’est douloureux de livrer, c’est long, il y a un tas de process et d’actions à faire…
• On va s’assurer d’avoir suffisamment de choses dans la release pour livrer. C’est long alors il faut que ça vaille le coup.
• On ne livre pas le vendredi. On ne peut rien modifier en août et fin décembre. On a un code freeze pendant les périodes avec beaucoup de vacances.

Automatisation

Créer une archive de l’application et l’envoyer sur un serveur, générer le fichier de traduction à partir d’une feuille Excel, remplacer toutes les majuscules d’un fichier brut par des minuscules et le transformer en JSON, … Ce sont des exemples de tâches manuelles qui gagneraient à être automatisées.

La bonne nouvelle ? Un développeur est bien placé pour automatiser, il est capable d’écrire du code pour créer un programme qui va effectuer ces tâches. Une fois créé, il n’y a plus qu’à exécuter ce programme et la tâche sera réalisée (souvent) immédiatement plutôt que de prendre trop de temps à une personne. On s’enlève au passage le risque d’erreur humaine : le programme fera toujours la même chose, il ne va pas oublier une ligne, il ne va pas se tromper de caractère, etc.

Outre l’efficacité, je trouve que c’est bien plus intéressant à faire. On conçoit un programme, on réfléchit plutôt que de répéter des tâches rébarbatives.

Livraison Continue

Le principe est simple, chaque changement sur la branche principale est livré. C’est livré dans un environnement de staging/test/preprod, ou même de production, mais ce n’est pas déployé. Ce n’est pas encore dans les mains des utilisateurs.

Autrement dit, avec la Livraison Continue, il suffit d’un simple bouton pour déployer aux utilisateurs, il n’y a pas besoin d’autres interventions. Tout est déjà prêt, on est capable de déployer sur demande. Plusieurs fois par semaine, jour, heure, etc.

Ça ne veut pas dire qu’on va forcément livrer chaque heure. Si on est capable de livrer toutes les heures, on est capable de livrer quand on veut. Et c’est ça que l’on recherche. Le déploiement devient un non-sujet. On pourra bénéficier des avantages de livrer souvent et rapidement de petits incréments, dès que cela fait sens.

Pour livrer en continu, on va mettre en place certains outils, on va automatiser des tâches, et on va s’atteler à toujours avoir un code dans un état déployable.

Déploiement Continu

Ici, on va un cran plus loin : tout est automatisé, il n’y a plus aucune intervention humaine. Chaque modification sur la branche principale est déployée en production et arrive directement dans les mains des utilisateurs.

En mettant en place la Livraison Continue ou le Déploiement Continu, on entre dans un cercle vertueux de pratiques. On se concentrera davantage sur la qualité, sur les tests automatisés, sur la création de petits incréments, sur l’activation à distance de fonctionnalités, … plutôt que sur des pratiques contraignantes comme mettre un freeze de code, avoir une semaine de tests de non-régression, avoir 4 niveaux de validations de chefferie, etc. Ce qui fera livrer moins souvent, donc il faudra faire encore plus attention, donc livrer moins donc faire plus attention, et ainsi de suite, un cercle vicieux de peur et de contrôle.

Améliorer un existant

• *On a des problèmes de qualité dont on n’a jamais le temps de s’occuper. *
• Mon équipe veut négocier un sprint ou deux de refactoring mais je ne sais pas quelle valeur ça va apporter.
• J’ai un développeur qui fait du refactoring depuis 3 mois, c’est pas encore fini mais il avance.

Refactoring

Faire du Refactoring, c’est changer le code sans casser son comportement observable. On améliore le code dans le but de mieux le comprendre ou de faciliter le changement, par exemple. Le code fera toujours la même chose. Si je fais du refactoring sur une fonctionnalité de recherche, elle fera toujours de la recherche, ni plus, ni moins.

Autre aspect très important du refactoring : on avance par petites étapes. On enchaîne une série d’améliorations, de petites étapes que l’on peut partager régulièrement. Le projet est toujours dans un bon état, on peut s’arrêter à tout moment.

C’est différent de “tout refaire”, à ne pas confondre avec la réécriture. Ce n’est pas ce fameux chantier de 3 mois en tunnel où rien ne fonctionne entre temps. Le refactoring demande de la discipline et des compétences.

Refactoring opportuniste

On fait du refactoring quotidiennement, toutes les occasions sont bonnes. J’ouvre un fichier où je vais devoir travailler, mais le changement est difficile ? Le code est legacy ? J’en profite pour faire un petit refactoring en amont plutôt que d’empirer. On peut évoquer la règle de Boy Scout :

Toujours laisser le code dans un meilleur état que celui dans lequel vous l'avez trouvé.

On préférera agir régulièrement et de manière opportuniste plutôt que de bloquer des jours/semaines dédiés au refactoring. Tout comme les tests, ça fait partie intégrante du job de développeur. Il est important de faire du refactoring régulièrement et de se former. D’ailleurs, au lieu de bloquer des jours pour faire du refactoring, peut-être le transformer en un temps pour se former et s’améliorer dans les techniques de refactoring ?

Théorie de la vitre brisée

On veut faire du refactoring régulièrement pour améliorer le code continuellement. On veut éviter que la situation ne s’empire, on veut y remédier au plus tôt. La théorie de la vitre brisée est intéressante pour expliquer pourquoi on veut agir vite et régulièrement.

Prenons par exemple une maison avec une fenêtre brisée. La théorie nous indique que si on ne fait rien, on laisse penser que la maison est à l’abandon. On va alors attirer et cumuler d’autres problèmes, des graffitis, de nouvelles fenêtres brisées, etc. Un cercle vicieux démarre et qui ira au-delà de la maison, apportant plus de criminalités dans le quartier.

Il faut remédier aux problèmes au plus vite, avant qu’ils ne soient trop nombreux. Un quartier où les maisons sont constamment bien entretenues attirera moins les problèmes. C’est la même chose avec le code, on va vouloir rester dans un état d’esprit de qualité.

Méthode Mikado

La méthode mikado est très utile pour faire du refactoring. C’est une méthode pour effectuer de grands changements avec de petites étapes. On veut atteindre un objectif, qui peut être ambitieux, on ne sait pas encore comment y aller, mais on va construire ce chemin progressivement.

On va effectuer une suite de petites expérimentations. Quand une expérimentation réussie, on a avancé vers notre objectif, avec une petite étape. Quand une expérimentation échoue, on revient en arrière, on a appris quelque chose, et on découvre qu’il faut effectuer une autre petite étape nécessaire en amont. On dessine d’ailleurs un graphe pour visualiser notre progression et nos pré-requis.

De fait, on est toujours dans un état fonctionnel, on peut s’arrêter à tout moment. On n’aura peut-être pas atteint l’objectif, mais ce sera mieux, on sera plus proche de la fin, on aura réalisé quelques petites étapes, et ça fonctionnera toujours.

Bref

On a vu un ensemble de pratiques tech reconnues dans l’industrie. On a vu comment elles peuvent aider dans certains problèmes. Et même au-delà. Ce sont des pratiques pour améliorer le quotidien de l’équipe et devenir meilleur dans la technique et dans le business.

On a aujourd’hui le recul nécessaire et les études pour voir la corrélation entre la performance technique et business. Pour répondre rapidement aux besoins de l’utilisateur, on a besoin de pouvoir livrer rapidement. Changer facilement le code permet de changer facilement de direction fonctionnelle.

Ma réponse est NON (sans surprise, comme la plupart des articles qui commencent avec une grande question fermée). Un développeur doit être autonome et décider de lui-même pour ce genre de pratiques. Il n’a pas à demander l’autorisation à un manager, ni un chef, ni un PO, ni un SM, ni même à un tech lead ou un autre développeur.

Encore moins se voir interdire (anecdote récente lors d’un entretien technique, un développeur m’a indiqué que son client lui interdisait d’écrire des tests parce que ça prenait du temps). Au contraire, il faut promouvoir et pousser ces pratiques aux développeurs et aux équipes.

Ça fait partie du job

L’écriture de tests, le TDD, le Refactoring, le Pair Programming, et j’en passe, ce sont des pratiques répandues dans l’industrie. Elles sont reconnues et proviennent de mouvements comme le Software Craftsmanship, l’eXtreme programming, ou le Domain Driven Design. Ce n’est pas le n-ième nouveau super framework à la mode.

On parle ici de pratiques qui améliorent la qualité du code et du produit, qui facilite le changement, qui permettent de mieux collaborer, de mieux retranscrire le métier. Elles font partie intégrante du métier de développeur.

Un développeur n’est pas un exécutant. Il n’est pas là juste pour pisser du code. Il a un (grand) rôle à jouer pour concevoir un produit de qualité. Il existe de nombreux ouvrages sur ces pratiques et également sur la posture de développeur. Pour en citer un, Sandro Mancuso en parle très bien dans son livre The Software Craftsman.

Just do it

Je donnerais comme conseil aux développeurs de faire, de passer à l’action, d’utiliser ces pratiques. Sans attendre une permission officielle, sans aller chercher une approbation quelconque. Faites-le, tout simplement.

Il y a un proverbe qui dit Il vaut mieux demander pardon que demander la permission. Je l’aime bien, et je trouve qu’il a du sens dans cette situation. Vous êtes développeur et vous hésitez ? Lancez-vous, essayez, montrez par l’exemple. Probablement, quelque chose de bon en sortira et on ne viendra pas vous taper sur les doigts. Ce n’est pas parfait ? Vous deviendrez meilleur en continuant d’essayer et de vous améliorer.

Rappelons que le développeur a l’expertise. Il sait comment travailler, il connaît sa boîte à outils. Mon propos n’est pas d’enfermer le développeur dans sa vision - il doit rester ouvert, comme tout le monde - mais de lui faire confiance et de lui donner de l’autonomie.

Ce qui n’empêche pas de le challenger. Et quand on touche à ses limites, à sa zone où il ne maîtrise pas, on se penchera plutôt sur comment former, comment apprendre, comment expérimenter, plutôt que d’empêcher.

Former les équipes

Ça fait partie du job, d’utiliser ces pratiques, ça fait également partie du job de se former. Elles ne tomberont pas soudainement du ciel. Avis aux développeurs qui doivent faire l’effort autant qu’aux managers qui doivent investir ;)

On se forme, on forme les équipes, on expérimente, on s’améliore en continue. Le retour sur l’investissement est positif, on ira plus vite, on délivrera mieux. On veut démarrer un cercle vertueux (on apprend, on améliore le code, on change plus facilement, on livre plus vite, on satisfait davantage l’utilisateur) plutôt que vicieux (on empêche, on n’apprend pas, le code se détériore, les évolutions deviennent difficiles, on cumule des problèmes, on met du temps à livrer à l’utilisateur).

Il y a un tas de moyens pour apprendre. Quelques idées : inviter des personnes à faire un BBL, l’intervention de coachs, faire des katas seul ou en groupe, du mob-programming sur le projet, assister à des conférences, lire des livres, etc.

Casser les idées reçues

Et s’il y a du blocage, des interdictions, des permissions à demander pour utiliser ces pratiques ? J’essaierais de comprendre pourquoi, de challenger, de rappeler que ça fait partie du job, et de casser certaines idées reçues.

En rappelant la vision, la philosophie de certaines pratiques. Le refactoring, ce n’est pas un chantier de 3 mois en tunnel. Ce sont des petites étapes, ce sont des améliorations que l’on fait au quotidien, qui facilitent le changement, qui améliorent la qualité.

L’écriture de tests et le TDD, ce n’est pas plus long. C’est une aide pour le développeur, un guide pour bien retranscrire le métier, le comportement. On obtient en plus de la sérénité quand il faut effectuer des changements. On entre dans des situations où l’on ira plus vite.

Le Pair-Programming, ce n’est pas juste deux ressources humaines qui se mettent sur un poste pour travailler sur un seul problème à la fois. C’est une collaboration poussée, c’est un feedback rapide, c’est une transmission de connaissances, d’informations, c’est de l’amélioration en continue. Là aussi on entre dans des situations où l’on ira plus vite.

On améliore la qualité, on gagne du temps, on gagne de l’argent. Trois arguments que l’on peut aligner en fonction de l’interlocuteur. On pourrait citer en touche finale Accelerate, un livre qui montre, via une étude sur plusieurs années incluant de très nombreuses entreprises, qu’il y a une corrélation entre la performance technique et la performance business.

J’ai la conviction que ça ne prend pas forcément plus de temps de travailler en TDD. On est sensiblement sur la même longueur, parfois même plus rapide parce que ça nous guide. On est très loin du laïus “c’est une perte de temps”, surtout lorsque l’on regarde sur différents horizons de temps.

Il n’y a d’ailleurs pas que le temps qui entre en jeu, d’autres bénéfices gravitent autour de l’écriture des tests et de la pratique du TDD. Pour étayer mes affirmations, j’ai envie d’en parler à travers plusieurs prismes.

J’ai une mauvaise utilisation du TDD

Pour le premier prisme, je prends un développeur qui pratique le TDD mais qui l’utilise mal, qui ne le maîtrise pas. Je commence par ce postulat parce que c’est sûrement là qu’il y a le plus de confusion et de mécompréhension. Les personnes qui ne maîtrisent pas l’art de tester et du TDD se forgent un avis sur la base d’une expérience incomplète.

Qu’est-ce que c’est, ne pas maîtriser ? Penser que ça se résume à écrire un test en premier, que c’est purement de la technique (versus métier), ou que ça se limite à suivre le Red-Green-Refactor, par exemple.

En adoptant une mauvaise pratique, on va se mettre des bâtons dans les roues. On va vouloir tout mocker, on va tester l’implémentation, on ne va pas faire de petites étapes, etc. Résultat, on va trouver ça plus long. On va peut-être préférer ne pas faire de TDD, finalement. C’est plus long et il y a un tas de trucs chiants à faire, pourquoi s’emmerder.

Dans ce contexte, la méthode est mal comprise et mal appliquée. C’est probablement plus long de pratiquer le TDD, oui. Mais peut-on juger la méthode dans ces conditions ? J’y répondrais par une autre question. Est-ce qu’une voiture est lente parce qu’on roule avec le frein à main ? Ou parce qu’on ne sait pas comment passer les vitesses ? Non.

=> Oui, une mauvaise application du TDD peut demander davantage de temps. Non, dans ce contexte, c’est inexact de déduire qu’une bonne pratique du TDD prend du temps.

J’apprends le TDD

Dans ce second prisme, j’introduis une nuance : un développeur qui s’exerce à pratiquer le TDD mais qui ne le maîtrise pas encore parce qu’il est en phase d’apprentissage. La différence avec le premier prisme ? Il a conscience de la bonne pratique du TDD et il s’améliore pour y arriver. Il ne va pas mal faire tout en supposant qu’il maîtrise la méthode.

Disons les choses. Le TDD, c’est difficile. Ça demande du temps pour le maîtriser. Ça demande de s’entraîner, de répéter, de s’améliorer. Mais pour autant, c’est la phase d’apprentissage qui requiert du temps. Ce n’est pas l’application de la méthode elle-même. Encore une fois, juge-t-on la vitesse d’une voiture avec un pilote qui apprend à passer les vitesses ? Non.

Ok. Et durant cet apprentissage alors, à quel point ça prends du temps de faire du TDD ? Ça dépend. Ça dépend du contexte, ça dépend du niveau de compétence que l’on a acquis à cet instant.

Il y a des situations où l’on ne sera pas encore à l’aise, on devra ralentir pour bien faire, on prendra davantage de temps sur le moment. À l’inverse, il y a des situations où l’on sera guidé par le TDD et où l’on obtiendra plus rapidement un bon résultat. On va commencer à bénéficier des effets positifs (j’en parlerais après).

=> Oui, l’apprentissage du TDD demande du temps. Non, on ne peut pas dire que la pratique elle-même, une fois maîtrisée, prend du temps.

J’écris mes tests après

Je me mets maintenant dans le prisme d’un développeur qui écrit ses tests après coup. Que se passe-t-il si je me mets à faire du TDD ? On pourrait se dire que l’on va prendre davantage de temps, on écrit déjà des tests, pourquoi se compliquer la vie à s’ajouter une méthode ?

Eh bien, dans ce contexte, pratiquer le TDD sera probablement plus efficace et plus rapide. Le TDD va guider l’écriture de l’implémentation. On obtiendra une meilleure conception, on avancera par petites étapes et on sera guidé par le comportement métier. Ce sera une aide pour écrire de meilleurs tests et un meilleur code.

De fait, on s’évitera les pièges d’écrire du code non-testable, d’en faire trop, ou de ne pas correctement retranscrire le métier, comme on pourrait le faire en écrivant les tests a posteriori.

En écrivant les tests après, on subit l’implémentation. Et plus on attend pour tester, plus on subit. Il y aura davantage de changements à effectuer, le coût va augmenter. Le refactoring sera d’ailleurs difficile ; les tests ne sont pas écrits, on n’a pas encore notre filet de sécurité en place.

=> Non, ce n’est pas plus long de pratiquer le TDD lorsque l’on écrit déjà des tests a posteriori. C’est un gain de temps, et en plus, un gain de qualité.

Je ne teste pas

Je termine avec un dernier prisme qui n’en ait pas moins intéressant : celui du développeur qui ne teste pas. Alors là, réflexe, on va se dire que c’est bien plus long. Non seulement, il faut écrire du code supplémentaire (les tests), et en plus, il faut se coltiner une discipline stricte. On va perdre du temps, non ? Je propose de regarder sous deux horizons de temps.

Court terme

À court terme, sur l’instant, le TDD va nous guider. C’est une de ses principales forces. Il nous guide pour concevoir le code de production, l’implémentation. Il nous guide pour retranscrire le métier. Il nous offre une boucle de feedback extrêmement rapide pour créer et améliorer.

On prends le temps de bien faire et de réfléchir, mais pour autant, ce n’est pas forcément plus long. Parce qu’on se concentre sur l’essentiel en progressant par petites étapes, parce qu’on est guidé pour coder l’implémentation, parce qu’on a un feedback rapide contrairement aux tests manuels.

La pratique du TDD ne va pas seulement nous faire écrire des tests avant de coder, elle va nous aider à coder, à concevoir. Au final, on ralentit tout en gagnant du temps, pour mieux faire. On passe sensiblement le même temps à développer notre fonctionnalité.

Dans certains contextes, on est plus rapide, parce qu’on se serait perdu en chemin sans le TDD, parce qu’on aurait fait trop compliqué ou parce qu’il y a beaucoup de logique. On perd vite du temps à explorer sans test et sans guide. Dans quelques autres contextes, ça peut être plus long de pratiquer le TDD, mais c’est sans compter les effets obtenus à plus long terme.

Moyen et Long terme

À moyen et long terme, on va obtenir de nouveaux bénéfices grâce à la pratique du TDD. Les tests vont couvrir notre code et vont faciliter le refactoring et réduire les régressions. On va gagner du temps.

La facilité de faire du refactoring va aider à améliorer continuellement le système. On va le maintenir et le faire évoluer plus facilement. On va le changer facilement. On va gagner du temps.

On aura du code et des tests qui reflètent mieux le métier et les cas d’utilisations. On va mieux comprendre notre système. On va mieux échanger avec les autres. On va gagner du temps.

Bref

Au final, en regardant à travers ces différents prismes, on peut observer que les situations où un développeur trouve que c’est plus long de pratiquer le TDD est peut-être à décorréler de la méthode elle-même. Souvent parce qu’elle n’est pas encore maîtrisée.

Dès lors qu’on a une bonne pratique du TDD, des bénéfices apparaissent immédiatement, à court terme. La force que le TDD propose pour guider et donner du feedback rapide est assez puissante pour être d’une grande aide pour le développeur tout en ne faisant pas perdre de temps.

Ces effets s’accentuent à plus long terme, et d’autres viennent s’ajouter. On y voit un cercle vertueux d’amélioration continue. Ce n’est plus juste une question de temps, on y gagne sur plusieurs niveaux.

Ce n’est cependant pas une décision à prendre à la légère. Certaines raisons sont parfaitement justifiées, alors que d’autres peuvent nuire au projet. Pourquoi a-t-on besoin de casser une dépendance dans certains tests ? Et de quoi veut-on être indépendant ? À quoi faut-il faire attention ? C’est de tout ça dont j’ai envie de parler aujourd’hui.

Qu’est-ce qui nous pose problème ?

Commençons par le commencement. On veut savoir pourquoi rendre un test indépendant, regardons du côté des problèmes auxquels cette envie d’indépendantisme répond.

Test déterministe

Avoir des tests qui échouent sans raison apparente à première vue, c’est embêtant. Encore plus lorsque ça semble être aléatoire. Et parfois, on a un passage au rouge du jour au lendemain, ce qui nous vaut la célèbre phrase “ça marchait avant”. Un test devrait avoir une intention claire et n’avoir qu’une seule raison d’échouer. On n’a pas envie de se lancer dans une session de debug pour comprendre ce qu’il se passe.

Alors qu’est-ce qui peut bien causer ces problèmes ? Un autre test. Ce bienfaiteur qu’est le test peut en effet être une source d’ennuis pour d’autres tests. Lorsqu’on lance un ensemble de tests, l’environnement et la mémoire sont partagés entre eux. Si deux tests lisent et écrivent dans un même endroit, ils vont éventuellement affecter le résultat de l’autre. Vous voyez où je veux en venir ? Base de données, fichiers, singletons, variables globales, … Tout ça représente une zone partagée et peut créer un lien de dépendance entre deux tests.

On arrive donc à notre première et principale raison. Pourquoi rendre un test indépendant ? Pour éviter un effet de bord venant d’un autre test. C’est dans ce but que l’on va casser une dépendance envers une base de données, un système de fichiers ou un singleton. Et que l’on mettra une fausse implémentation, avec un base de données en mémoire par exemple, pour avoir un état déterministe.

C’est d’ailleurs une autre raison, être déterministe. On veut rendre un test indépendant pour obtenir toujours le même résultat. Du côté des causes, on retrouvera celles vues précédemment et on peut notamment y ajouter d’autres éléments perturbateurs comme les requêtes HTTP, la date du jour, les fonctions aléatoires (quoi de mieux qu’un bon random() pour avoir un résultat imprévisible ? :p). Ce sont des sources qu’on ne contrôle pas. Mais pour être déterministe, il faut les contrôler : on cassera alors les dépendances afin de les remplacer. Ou peut-être que l’on s’orientera vers la création de fonctions pures.

Test rapide

Ajoutons un autre problème, sinon ce n’est pas marrant. Une suite de tests lente à exécuter est assez fâcheux. Les tests unitaires nous guident dans la conception et parfois nous rattrapent lors de sorties de route. On a besoin d’un feedback rapide, et encore plus lorsque l’on pratique le TDD.

On aura une nouvelle fois les mêmes fautifs. Feraient-ils preuve d’intelligence ? On se le demande, mais en tout cas ça nous arrange puisqu’il n’y a pas de centaines de causes différentes. Principalement, tout ce qui accède au réseau, aux internets, ralentira fortement vos tests. On peut rester dans la centaine de millisecondes comme dépasser aisément la barre des secondes. C’est sûrement la source la plus lente. Viennent ensuite les bases de données et le système de fichiers. Unitairement, le temps est peut-être faible, mais quand on dézoom et qu’on regarde le cumul sur l’ensemble des tests, ça devient (trop) long.

On en vient à notre dernière raison. On veut rendre un test indépendant pour qu’il soit rapidement exécuté. Là encore, on cassera éventuellement des dépendances qu’on substituera par quelque chose répondant immédiatement.

Couper les ponts

Si on résume en une phrase, on souhaite rendre un test indépendant afin d’éviter qu’il soit affecté par les autres tests, pour être déterministe, et pour être rapide. Voilà. Ce sont les raisons principales. Pas besoin d’aller chercher plus loin et d’isoler complètement un test.

Un autre moyen d’entrevoir ces raisons est de regarder du côté des principes FIRST. Ce sont des principes pour guider l’écriture des tests, et je trouve qu’ils reflètent bien les besoins d’indépendance. On parle de rapidité d’exécution (F pour Fast), de test indépendant des autres tests (I pour Independent) et de résultat déterministe (R pour Repeatable).

Quelques mauvaises compréhensions

Maintenant que nous avons bien en tête les raisons qui motivent les tests à devenir indépendant, revenons sur quelques mauvaises compréhensions. C’est essentiel d’en parler, car il peut y avoir un impact fort : tests fragiles, maintenance lourde, démotivation des développeurs.

System Under Test

Quand on parle de SUT, on parle de SYSTEM Under Test. Ce n’est ni Class Under Test ni Fonction Under Test. C’est très important. Le système, ce peut être une fonction, ou une classe, ou un ensemble de classes et de fonctions. Peu importe, on va tester l’ensemble et tout ce qu’il y a derrière. On peut voir ça comme un module, ou une boîte noire - on teste toute la boîte depuis notre point d’entrée.

On ne cherche pas à isoler le système que l’on teste des autres classes et fonctions qu’il utilise. On rend le test indépendant, oui, mais pas la classe. On s’en tiendra aux raisons évoquées plus haut pour casser des dépendances. C’est parfaitement ok qu’une méthode que l’on teste appelle d’autres classes, qui appelleront aussi d’autres classes.

Heavy mocking

En comprenant bien ce qu’est le SUT et ce qu’il faut rendre indépendant, on s’évite au passage la sur-utilisation de mocks. On ne va pas essayer de tout isoler et donc de tout mocker.

Le problème avec les mocks, c’est qu’ils connaissent trop les détails de l’implémentation. Si on change notre implémentation (on a une meilleure idée, on fait du refactoring), on va casser les tests. Les assertions vont être fausses et c’est normal, le mock vérifie la mécanique interne.

La sur-utilisation des mocks va entraîner des problèmes en cascade : on couple les tests à l’implémentation, on a du mal à faire du refactoring, le code devient difficile à changer, le développeur se démotive, il y a moins de tests, moins de qualité, fin. Vraiment, on ne veut pas coupler les tests à l’implémentation :)

Comportement

Ça me fait une bonne ouverture pour terminer. Ce que l’on veut tester, c’est le comportement. Quand on fait des applications, c’est pour répondre à un besoin métier. C’est ça que l’on veut tester. On se limitera à enlever les dépendances gênantes pour les tests unitaires. Testez le comportement plutôt que les détails de l’implémentation.

Crédits photos : Anne Nygård, Richard Lee.

Les katas de code forment un moyen très intéressant pour apprendre par la pratique. On découvre, on explore, on essaie, on répète, on améliore. Bref, on apprend. Et à l’image du vélo à roulette, on est dans un cadre sécurisé et simplifié.

Je fais des katas pour apprendre de nouvelles choses. Ces choses peuvent être très variées. Des langages par exemple. Je me suis amusé avec Kotlin, Typescript, Clojure, Elixir, Elm ainsi que F# récemment. Des langages très hétérogènes. Ça me permet d’agrandir ma vision, d’obtenir de nouvelles connaissances et d’être moins lié à un éco-système ou à une façon de faire. Via les katas de code, j’apprends aussi des concepts comme CQRS et Event-Sourcing, ou le Mutation Testing. Je m’entraîne à toujours mieux concevoir mon code, le rendre plus simple, plus compréhensible, à mieux retranscrire le métier.

Avec les katas, je répète des gestes pour parfaire ma maîtrise. Le mot kata est d’ailleurs un terme japonnais qui vient des arts martiaux. Le but est de travailler des techniques en toute sécurité en répétant des gestes. On apprend par la répétition dans un environnement dédié à l’apprentissage (ce n’est pas un vrai combat). J’utilise les katas de code pour répéter l’écriture de tests, le TDD, le Refactoring. C’est par une longue pratique et des contextes différents que l’expérience vient. On n’acquiert pas une maîtrise après avoir lu un article et une vidéo sur YouTube. Je vais parfois faire plusieurs fois le même kata de manière différente, et parfois répéter la même manière mais sur des katas différents.

La nature éphémère et simple d’un kata de code apporte un cadre favorisant l’apprentissage (à opposer avec un projet perso ou la production en entreprise). Je peux expérimenter comme bon me semble, je peux recommencer autant que je veux, je peux prendre le temps que je veux. Je choisis mes contraintes. Il n’y a pas de mise en danger ni d’impératif.

Il n’y a pas d’âge pour faire des katas de code. Je suis Junior, je suis Senior, je sors d’école, j’ai 12 années d’expériences… En fait, la bonne affirmation serait plutôt j’ai toujours à apprendre et à approfondir. Que ce soit dans notre domaine de prédilection ou dans d’autres qui restent à explorer. Je fais partie d’un groupe de kata pour coder et réfléchir ensemble, composé de développeurs expérimentés. Malgré tout, on continue d’apprendre et de se casser quelques dents. Et on aime ça.

Je fais des katas seul, pour explorer ce que je veux, quand je le veux. Et je fais également des katas en groupe pour démultiplier mon apprentissage. En mob-programming, nous partageons, nous discutons, nous confrontons des visions, nous essayons différentes solutions. Nous nous ouvrons et nous apprenons les uns des autres.

C’est tout ça, pour moi, la magie des katas. C’est un très bon levier d’apprentissage et terrain de jeu. Bien sûr, ce n’est ni le seul moyen d’apprendre, ni suffisant. Je vais aussi lire des livres pour obtenir plus de théorie et de profondeur, assister à des conférences, pratiquer sur des projets réels, etc.

Votre prochain kata

J’en arrive à la fin de ce que je voulais raconter. Il me reste à vous partager des liens pour trouver vos futurs katas de code ainsi qu’une petite sélection de ceux que j’apprécie, puis je retournerais m’amuser.

Je ne peux parler de kata sans mentionner Emily Bache. Coach et auteur du livre Coding Dojo Handbook, Emily possède un compte GitHub qui fourmille de katas (un grand merci à elle). Elle les prépare et les utilise pour accompagner des équipes; vous en aurez pour tous les goûts.

Certains sites et pages GitHub recensent également des katas. En voici trois que j’utilise régulièrement pour piocher des sujets : Coding Dojo, Kata-log et Awesome Katas. Et n’oubliez pas votre moteur de recherche préféré, il se fera un plaisir de vous en faire découvrir d’autres.

En ce moment, je suis sur un kata bien sympa qui reprend les mécaniques d’un jeu de carte dans le style de Hearthstone, le Trading Card Game. J’aime également le Bank Account, le Mars Rover, le Game of Life et le GildedRose. Ils font partie de mes classiques. Ils sont simples et très efficaces. Ils permettent de s’amuser avec de multiples concepts différents et d’expérimenter plusieurs solutions.

Vous voilà avec de nombreuses raisons de vous lancer, et toute une liste de katas potentiels. Bon apprentissage !

Voici donc un premier guide pour Kotlin. Je le partage pour m’aider moi ou quiconque voudra se lancer rapidement dans un petit projet de code avec des tests. C’est un essentiel à l’instant T, je le mettrais possiblement à jour dans le temps avec de nouvelles choses. Si vous avez des remarques, je suis preneur.

Création d’un projet

Il existe d’autres solutions, mais je ne parlerais que de Gradle qui est plus récent et qui est recommandé.

Via Intellij IDEA

JetBrains a créé le langage et l’outillage. La création d’un projet Kotlin est simple et rapide. On passe par le menu : File > New > Project.

Les possibilités changent ensuite selon l’édition de Intellij et/ou du système d’exploitation je suppose.

Si vous avez la possibilité, sélectionnez Kotlin puis Console Application. Gradle y sera ajouté par défaut. La documentation officielle va dans ce sens. Sinon, si vous êtes comme moi sur macOS avec l’édition Intellij IDEA CE, sélectionnez Gradle puis cochez Kotlin/JVM.

Plus d’informations : https://kotlinlang.org/docs/jvm-get-started.html

En ligne de commande

La simplicité est également présente en ligne de commande. Il suffit d’exécuter gradle init puis de se laisser guider. Ce que je choisis en général :

• Type of project : application.
• Implementation language : Kotlin.
• Script DSL : Groovy ou Kotlin.

Exécution du projet et des tests

Via Intellij IDEA

D’un clic-droit sur un module ou un fichier dans l’arborescence, il est possible de compiler le projet, lancer le projet, et lancer les tests.

Les résultats des tests sont visibles dans un des onglets du bas d’Intellij IDEA. Il est possible de voir tous les tests, ou de filtrer selon le succès ou l’échec.

⚠️ Kotest : Parfois, il faut aller sur le menu latéral « Gradle » et cliquer sur Tasks > verification > test. Lancer la tâche « test » manuellement pour voir tous les tests se lancer. Problème dû à kotest ou à la présence de plusieurs frameworks de tests ?

En ligne de commande

Le projet étant créé avec Gradle, on passera toujours par la commande gradle pour effectuer des actions.

• Lancer les tests : gradle test
• Lancer les tests automatiquement (watch mode) : gradle test —continuous
• Lancer l’application : gradle run

Choix de l’IDE

Intellij IDEA

Sans hésiter, je dirais d’utiliser Intellij IDEA. JetBrains a un très bon savoir-faire. L’IDE est très complet en termes de fonctionnalités, les possibilités de refactoring sont nombreuses, et l’écosystème Kotlin est très bien intégré. La version communautaire est en plus gratuite.

On trouve toutes les options de refactoring à l’aide du raccourci Ctrl + T.

Gestion des dépendances

Le fichier de configuration principal est build.gradle (Groovy) ou build.gradle.kts (Kotlin).

Pour ajouter des dépendances, on est souvent amené à insérer des lignes dans l’étape nommée dependencies. Par exemple :

dependencies {
    testImplementation 'org.jetbrains.kotlin:kotlin-test-junit5'
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.0'
    testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.6.0'
}

⚠️ Lorsque l’on ajoute une nouvelle dépendance, il faut vérifier que celle-ci ne va pas entrer en conflit ou n’est pas en double (sous une autre version). Ce peut être le cas lorsque l’on initialise le projet en ligne de commande et que l’on ajoute les dépendances de JUnit. L’erreur est difficilement visible : au lancement des tests, aucun d’eux n’est trouvé.

⚠️ Il existe plusieurs sources pour récupérer les dépendances : les repositories. Il peut être nécessaire de changer ou d’ajouter une source pour résoudre les dépendances.

⚠️ Après un changement dans le fichier de configuration, il peut être nécessaire de recharger Gradle dans Intellij IDEA. Une petite icône Gradle est peut-être apparue par-dessus le contenu du fichier.

Variables

On peut définir des variables dans le fichier de configuration. Exemple en Groovy :

def kotestversion = '4.4.3'

dependencies {
    testImplementation 'org.jetbrains.kotlin:kotlin-test-junit5'
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.0'
    testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.6.0'
}

⚠️ Les variables ne peuvent pas figurer dès le début du fichier.

⚠️ Il faut faire attention à bien utiliser les double quotes. Certaines documentations comme celle de kotest donnent des instructions qui ne compilent pas.

Écrire des tests unitaires

Tests unitaires classiques

JUnit fonctionne très bien avec Kotlin sur JVM. Il suffit d’annoter la fonction avec @Test et d’utiliser un des assert. Voir documentation officielle pour ajouter la dépendance.

@Test
fun testSum() {
    val expected = 43
    assertEquals(expected, classForTesting.sum(40, 2))
}

Assertions et matchers

JUnit propose quelques assert classiques. On peut y ajouter les matchers de Kotest (une des sous-dépendances) pour avoir davantage de possibilités.

name shouldBe "sam"

"substring".shouldContain("str")
           .shouldBeLowerCase()

mylist.forExactly(3) {
    it.city shouldBe "Chicago"
}

Parameterized tests

JUnit propose un moyen de rendre une fonction de test paramétrable grâce aux annotations @ParameterizedTest et @MethodSource. La fonction de test acceptera alors des paramètres en entrée pour jouer le scénario avec différentes valeurs. Kotest le permet également à sa façon.

internal class MarsRoverTest {

    companion object {
        @JvmStatic
        fun leftCommands() = listOf(
            Arguments.of("N", "W"),
            Arguments.of("W", "S"),
            Arguments.of("E", "N"),
            Arguments.of("S", "E")
        )
    }

    @ParameterizedTest(name = "The new direction is {1} with initial direction {0}")
    @MethodSource(value = ["leftCommands"])
    internal fun `Should turn left`(initialDirection: String, newDirection: String) {
        val world = World(3,3)
        val marsRover = MarsRover(position, initialDirection, world)

        marsRover.execute(listOf("L"))

        marsRover.direction shouldBe newDirection
    }
}

Property-based Testing

Kotest permet de faire du Property-based Testing via de nombreux générateurs et apporte plusieurs fonctionnalités (shrinking, repeatable random seeds, …). Ajout de la dépendance et utilisations sur la documentation officielle.

class PropertyExample: StringSpec({
   "String size" {
      checkAll<String, String> { a, b ->
         (a + b).length shouldHaveLength a.length + b.length
      }
   }
})

Code Coverage

Plus tard :)

Mutation Testing

Plus tard :)

Apprendre le langage

Selon les goûts et les couleurs, voici plusieurs moyen d’apprendre Kotlin.

• La documentation officielle. On y trouve un tas d’explications, d’exercices et de ressources autour du langage.

• Les Koans. De petits exercices pour apprendre par petites étapes, en étant guidé dans différents thèmes.

• Learn X in Y minutes sur Kotlin. Un condensé de ce qu’il faut savoir sur n’importe quel langage.

• La convention de code officielle. Afin de ne pas se faire taper dessus par les puristes.

REPL

Plus tard :)

I am jealous of the experience Visual Studio offers with C# and the Live Unit Testing feature. Each line of the code is decorated with a symbol indicating if it is covered by passing tests or failing tests, in real-time. Awesome. I need something like that.

I started by searching a similar tool for the languages I use. Then I created a simple script, which runs a command after each file change. Finally, I found a really nice tool for file change monitoring. It is powerful, cross-platform, and open-source. And that’s what I want to talk to you about.

Watch my changes! 🔍

One way to improve the feedback given by our tests is to know immediately if a change breaks a test. To achieve this goal, we have to continually run tests. The more often we run the tests, the smaller the failing piece of code will be. Ideally, tests should be run after each change. But we can easily forget, or it can be cumbersome.

So we need a way to monitor files and automatically execute a command if there is a change. Some languages and tools offer a built-in way to do that. For example:

• Kotlin through Gradle > gradle test —-continuous
• Elm with elm-test > elm-test --watch

But what if the programming language and tool we are using do not have a watch option? This is where fswatch comes in.

fswatch 📡

Open-source and cross-platform, fswatch is a great tool to monitor file change. It provides recursive directory monitoring, filtering, and supports many OS-specific APIs such as kevent, inotify, and FSEvents.

By using these low-level APIs, fswatch is able to detect any changes in your specified paths and to send informations to another command. The tool is good enough to throttle the execution of the command: it will wait for the user to stop editing the code.

For more information about features or how to install it, please take a look at the GitHub repository.

https://github.com/emcrisostomo/fswatch

Usage

In most cases, you simply want to fire a command as soon as a change is detected in a folder. It’s as simple as this line:

fswatch -or YOUR_PATHS | xargs -n1 -I{} YOUR_COMMAND

fswatch accepts a list of paths to monitor. The o option asks the tool to group changes by batch, and the r option stands for watching subdirectories recursively. Events are then sent through xargs to your command. Here is an example for swift, observing one folder:

fswatch -or ./Project | xargs -n1 -I{} swift test

Note that fswatch will run until you stop it, by pressing Control + Z on macOS or Control + C on Linux for example. But that’s what we want, run indefinitely regardless of the test results.

Going further 🚀

So, you got the basics. Now we will see how to improve it.

Choose carefully the files to monitor

You may want to not run your tests for every kind of file changed. A change in an image or in a temp folder probably does not interest you. Observing the right files allows you to run tests only if an impacting change occurs. It can also prevent you from going into an infinite loop.

I had a case where build files were generated after each test, so that triggered the watch, and run tests again, and changes appear, and… this story will never end. The easiest solution for me was to specify multiple sub-directories as input to fswatch` instead of the whole project folder. Remember that you can set multiple paths.

fswatch -or ./Sources ./Tests | xargs -n1 -I{} swift test

The other way is to include or exclude paths matching a regex. According to the fswatch manual, you can set options like -i, --include and -e, --exclude for that.

Create a script

Sometimes, the command you want to fire for each change is long and requires a lot of parameters. It may even be composed of multiple commands. In that case, I recommend you to decompose this step and to create a script to run your tests.

fswatch -or ./Sources ./Tests | xargs -n1 -I{} run-tests.sh

Better, isn’t it? But we can still improve that. We can avoid typing that long line every time we start working. You see me coming, we’ll make a second script that will do it.

live-tests.sh

Keep it visible

Now that we have a real-time feedback, we want to see it. It would be a shame to have it hidden in the background. Good news, it is quite easy to keep a terminal in the foreground. Perhaps your favorite editor has already a panel with a terminal, and you just have to show it. Visual Studio Code, for instance.

Some editors like Sublime Text do not have a terminal panel by default, but you can add it with a plugin or extension. And if that’s not possible, you still have the option to put the terminal on a second screen, if you have one, or to reduce your editor window and put a terminal at the left, right, or bottom of it.

You have everything you need to get started. Monitoring files is at your hands. Enjoy the continuous and real-time feedback of your unit tests.

This is particularly interesting when comparing its speed with an iOS or macOS project. Compiling such a project takes tens of seconds or even several minutes. Running tests is therefore also slowed down.

Test-Driven Development is about getting feedback quickly. Wouldn’t it be interesting to get real-time results? Let’s see how we can leverage Playgrounds to write and run unit tests in Swift.

Writing unit tests

XCTest, the Apple framework for unit testing, is available through Playgrounds. Writing unit tests in Playgrounds is exactly similar to writing them inside a project with a unit test target. You just have to import XCTest and to write unit tests inside a test case class:

import XCTest

class HelloServiceTests: XCTestCase {
    
    func testMakeMessage() {
        // Arrange
        let now = 1587301244
        let dateProvider = FakeDateProvider(now: now)
        let service = HelloService(dateProvider: dateProvider)
        
        // Act
        let message = service.makeMessage()
        
        // Assert
        XCTAssertEqual(message, "1587301244 - Hello.")
    }
}

It does not change your habits. You write a unit test, instantiate a class, call a method and assert a result as you are used to. You can add as many tests and test cases as you want. See? Simple.

Running unit tests

The difference with a classic unit test target starts here, but that does not mean it will be complicated. Rather, it’s very simple. The solution fits in one line of code. Here it is:

HelloServiceTests.defaultTestSuite.run()

Results of unit tests will appear in the console. These are the same logs you can find in Xcode. Each time you are changing the code, unit tests will be automatically launched again and new logs will be printed.

But, why do we need this line? With an Xcode project, to run a test, we are usually pressing Cmd + U or choosing Product > Test from the menu. Behind the scene, the test target gathers every test case and test method while we are creating them. This list is then given to the test runner which will execute every test listed.

In a playground, this process does not exist really. We have to manually create a test suite (something containing all of the tests) and run it. If you want to know more about the behaviors of unit testing frameworks, I recommend you to take a look at xUnitPatterns.com.

Having multiple XCTestCase

Previously, I told you that you can write as many test cases as you want. So if you want to run all of thems, you will have to create and run all test suites. One way to do that is to call the run method on each default test suite. But there is a better way:

let globalSuite = XCTestSuite(name: "Global - All tests")
globalSuite.addTest(HelloServiceTests.defaultTestSuite)
globalSuite.addTest(FooTests.defaultTestSuite)
globalSuite.run()

The main advantage of creating a global test suite is to have numbers that aggregate all the cases. You will have results and failures for each test suite, and at the end, the global count.

Adding a suite to a suite is possible because everything is XCTest: XCTestCase and XCTestSuite inherit from XCTest. If you have multiple unit test targets in your project, you will see that your tests are grouped per class and target.

Improving errors

Reading errors through a long log isn’t the most attractive way to work in Test-Driven Development. There aren’t those little red or green badges next to every test. To improve our experience, we can use XCTestObservationCenter to observe the progression of test runs through an object implementing XCTestObservation.

class TestObserver: NSObject, XCTestObservation {
    
    func testCase(_ testCase: XCTestCase, 
                  didFailWithDescription description: String, 
                  inFile filePath: String?, 
                  atLine lineNumber: Int) {
        // Do something here.
    }
}

let testObserver = TestObserver()
XCTestObservationCenter.shared.addTestObserver(testObserver)

Multiple methods are responding to different events. The one in the example is called when a test case reports a failure. This is an opportunity to improve feedback.

We can add an assertionFailure, for example. In a playground, this statement will stop the execution. Because the log is written progressively, the last message will be our error message.

We can also code our data structure and have a better print, or whatever other behavior we want. And why not a live view?

Organizing files

As I see Playgrounds, it’s meant for easily and quickly prototype and try things. It can be difficult to make a big project with it, mainly because of the file management and the tree structure. However, we don’t have to do everything in one file.

Having multiple files

The Navigator, the left panel of Xcode and Playgrounds, is often hidden. Well, it’s understandable: we code almost all the time only in the main window and file. If you take a look at the Navigator, you can see a Sources folder.

Here, you can add every file we want. The Sources folder is considered as a different module by Playgrounds. It means two things. First, you need to explicitly set access levels to public on every object, method, or property you want to access. In a Swift module, the default access level is internal.

Second, the module is compiled when a change occurs in it, and only inside it. It’s a big gain of time. Editing code in the main file of the Playgrounds does not affect the module. It is why we can keep a really quick feedback.

Conclusion

It is easy to write unit tests and to run them in Playgrounds, and we are using tools that we already know. Playgrounds adds a very appreciable real-time execution for doing Test-Driven Development. The responsiveness of the feedback is really great, it’s a big advantage for the red-green-refactor cycle.

This is not perfect for handling multiple files of a big project, or displaying errors, but we have solutions to improve our experience. It’s not a big problem to work, to prototype, to explore.

In future articles, I will tell you about other ways to speed-up Test-Driven Development in Swift. We will see how we can use Swift Package or frameworks to help us. Keep in touch :)

Dans cet article, je vous propose d’explorer 5 principes qui pourront vous guider et vous challenger pour l’écriture de vos tests unitaires. Ces principes sont connus sous l’acronyme FIRST, signifiant avoir des tests :

• Fast 🚅
• Independent 📦
• Repeatable ♻️
• Self-validating ✅
• Timely ⏱

En s’inspirant de ces bonnes pratiques, la qualité de vos tests s’améliorera et la qualité du projet et du code de production suivra. Pour mieux comprendre ces principes, faisons le tour de chacun d’eux en explorant leurs raisons d’être, les possibles problèmes en cause et des pistes de solutions.

F : Fast 🚅

Exécuter un test doit être rapide, et surtout, lancer l’ensemble des tests doit être rapide. Cela inclut le temps des setup et teardown, et même de la compilation. Un test unitaire rapide mais avec une longue compilation ou un long setup est un test long. Si vous hésitez pour lancer vos tests après une modification, c’est que vos tests sont probablement trop longs.

Lorsque les tests sont longs, les workflow de développement et de déploiement sont ralentis. Par ailleurs, un des bénéfices des tests unitaires est d’obtenir un feedback rapide. Pour conserver cet aspect, il faut que les tests soient rapides.

C’est encore plus important lorsque vous utilisez un outil qui exécute automatiquement les tests unitaires impactés par vos modifications. C’est le cas en C# par exemple, avec Visual Studio et le Live Unit Testing.

Mais alors, qu’est-ce qu’un test long ? Prenons 150ms. Ça n’a l’air de rien, mais si chaque test prend 150ms, le cumul peut devenir bien plus long. Sur un projet ayant 2000 tests, et cela peut vite augmenter si l’équipe en ajoute régulièrement, on arrive à un total de 5 minutes ! Cumulé sur une journée, c’est énorme et c’est sans compter le temps de compilation ou de setup.

Un temps aussi grand va créer un point de douleur qui va démotiver le développeur, ce qui aura pour conséquence de diminuer la fréquence à laquelle il lance les tests. Dans le pire des cas, il pourrait même ne plus du tout lancer les tests.

Pour avoir un feedback rapide, il est nécessaire de lancer très souvent les tests pendant que l’on développe. En perdant le feedback rapide, on perd aussi du temps. On obtient bien plus tard l’information que quelque chose a cassé. De nombreuses modifications ont pu être ajoutées et il faut identifier laquelle est responsable de l’erreur.

Causes

Les dépendances lourdes comme les accès à une base de données, les appels réseaux, ou les lectures de fichiers sont souvent les responsables d’un test long. Ces opérations durent des centaines de millisecondes, voire plusieurs secondes.

Parfois, les traitements asynchrones ralentissent les tests par le traitement lourd qu’ils peuvent faire, et possiblement aussi par la manière dont les tests gèrent l’asynchronisme (le test étant bloqué tant qu’une réponse n’est pas arrivée). Le multithreading peut poser le même problème.

Solutions

L’injection de dépendance, ou le principe d’inversion de contrôle, est un moyen efficace de s’abstraire des dépendances. Les implémentations réelles sont remplacées par des simulacres, comme des Test Double, qui permettent de simuler des comportements.

En créant une classe qui agira à la place d’un service effectuant une requête HTTP, par exemple, on obtient la flexibilité d’avoir la valeur que l’on souhaite immédiatement. Retourner des objets prédéfinis dans une fonction est une instruction instantanée contrairement à un appel réseau.

class TimeoutArticlesProvider: ArticlesProvider {
        
    func fetchAllArticles(completion: ((Result<String, ApiError>) -> Void)) {
        completion(.failure(.timeout))
    }
}

I : Independent 📦

Un test ne doit pas dépendre d’un autre test. Le résultat d’un test ne doit pas non plus affecter un autre test. Cela peut causer des faux positifs ou cacher un problème. On perdrait du temps à parcourir plusieurs tests pour découvrir l’origine d’une erreur.

On devrait pouvoir lancer les tests dans n’importe quel ordre. De même, on devrait pouvoir lancer n’importe quel sous-ensemble de tests : un seul, une suite de plusieurs tests, ou tous. Si ce n’est pas le cas, c’est une indication que certains tests dépendent les uns des autres.

Tendre vers des tests indépendants permet de focaliser chaque test sur un comportement précis, ce qui donne davantage de sens au mot unitaire. Un test ne devrait avoir qu’une seule raison d’échouer. Cela permet d’identifier rapidement la cause d’une erreur, on comprend tout de suite pourquoi le test a échoué. On évite ainsi une longue session de debug.

On veut donc se rendre indépendant d’une base de données par exemple, pour éviter que l’écriture dans un test A affecte le résultat d’un test B. Ce peut être la même chose pour des singletons, des fichiers. Eventuellement, on va vouloir devenir indépendant de choses lourdes comme les appels réseaux, notamment pour respecter les principes Fast et Repeatable.

Attention à ne pas tomber dans l’extrême. On ne veut pas que le SUT (System Under Test) soit isolé de tout. Non. On veut seulement rendre le test indépendant. Le SUT peut être une classe comme un ensemble de classes, un module. Tout mocker posera des problèmes et rendra le test fragile.

Causes

Compter sur un enchaînement de plusieurs tests afin d’effectuer des actions prérequises à l’exécution d’un autre test va créer un lien de dépendance. De même que partager un état avec d’autres tests. On peut par exemple retrouver ces états dans des propriétés de la classe de test, dans des singletons, dans des bases de données, dans la lecture et l’écriture de fichiers… Bref, tout ce qui est partagé.

Solutions

Ici aussi l’injection de dépendance aidera à remplacer les dépendances gênantes pour le test. A celà, on peut ajouter le modèle Arrange-Act-Assert afin de structurer l’écriture d’un test en trois grandes parties en plus d’apporter de la rigueur et de la cohérence entre les tests.

• Arrange : on prépare toutes les données requises pour le test, ainsi que l’état dans lequel le test doit se trouver. On s’abstrait des autres tests et de l’environnement, ainsi que des dépendances en créant les Test Double nécessaires.
• Act : la méthode testée est appelée. Les données requises ont été initialisées dans l’étape précédente, et les dépendances injectées.
• Assert : on vérifie que le résultat est bien celui qu’on attend grâce aux différentes méthodes Assert du framework de test. Un test doit tendre à n’avoir qu’un seul assert pour n’avoir qu’une seule raison d’échouer. Dans certains cas, on peut avoir plusieurs assert lorsqu’ils se regroupent sous une même logique.

class HelloServiceTests: XCTestCase {
    
    func testMakeMessage() {
        // Arrange
        let now = 1587301244
        let dateProvider = FakeDateProvider(now: now)
        let service = HelloService(dateProvider: dateProvider)
        
        // Act
        let message = service.makeMessage()
        
        // Assert
        XCTAssertEqual(message, "1587301244 - Hello.")
    }
}

Un autre moyen de donner de l’indépendance aux tests est d’utiliser les méthodes de setup et de teardown. Ces méthodes sont respectivement appelées avant et après l’exécution de chaque test. Le teardown est très utile pour effectuer un nettoyage après chaque test, par exemple.

Le nommage des tests a son importance et peut aider à rendre des tests indépendants. Chercher à mettre en valeur l’intention du test à travers son nom force à tester un comportement plus précis. Et par la même occasion, cela facilite la compréhension pour déterminer pourquoi le test a échoué.

Certains frameworks ou IDEs proposent d’exécuter les tests dans un ordre aléatoire. Activez cette option. Vous aurez rapidement une idée quels tests ont un problème, et cela vous empêchera peut-être d’ajouter un nouveau test dépendant.

R : Repeatable ♻️

Un test doit toujours produire le même résultat. Toujours. Peu importe le nombre de fois où il est exécuté, la date ou le lieu. Si un test ne réagit parfois pas de la même manière, on ne peut pas lui faire confiance.

Comment savoir si la raison d’un échec est “normale” ou réellement problématique ? À quel point les erreurs sont bien détectées ? En se posant sans cesse des questions sur les tests, on perd en sérénité, rendant alors les changements dans le code plus difficiles et plus hésitants.

Pour un état de départ donné et une action exécutée, on doit pouvoir prédire la réponse. Sans résultat déterministe, les sessions de debug seront plus compliquées lorsque des erreurs surviendront (et idéalement, on n’a pas besoin de debugguer). Certains problèmes pourraient être difficiles, voire impossibles à reproduire à l’identique.

Un test doit éviter de dépendre de sources de données non-prévisibles. Des sources changeantes, pouvant être indisponibles, des états extérieurs ou des environnements sont des dépendances empêchant d’obtenir continuellement le même résultat.

Causes

Les bases de données sont des sources de données changeantes. Elles pourraient être modifiées par d’autres tests ou d’autres lancements. Les APIs web peuvent également exposer des données différentes à chaque appel, en plus d’être potentiellement indisponible (serveur en maintenance) ou inaccessible (panne de réseau).

Tester du code utilisant ces types de dépendances donnera un résultat incertain. Les singletons, les configurations et les environnements peuvent aussi être responsables d’un test ayant une sortie non garantie. Plus souvent oubliés : l’utilisation des dates et des fonctions aléatoires.

Solutions

On veut toujours avoir le même résultat, donc on veut contrôler entièrement le test, donc on doit rendre contrôlable certaines dépendances. L’injection de dépendance permettra de s’abstraire des sources de données non-prévisibles en ayant le contrôle sur les réponses générées. Par exemple, on peut simuler une requête échouant suite à un timeout pour les besoins d’un test, et par ailleurs simuler un succès pour un autre test.

Cette même solution peut être utilisée pour gérer les dates et les fonctions aléatoires. Pour cela, on transforme l’accès à la date en le rendant indirect, via une interface, afin d’ajouter une abstraction qui permettra de remplacer la valeur réelle par un Test Double dans les tests.

protocol DateProvider {
    var now: Date { get }
}

class DeviceDateProvider: DateProvider {
    var now: Date {
        return Date()
    }
}

class HelloService {
    
    private let dateProvider: DateProvider
    
    init(dateProvider: DateProvider = DeviceDateProvider()) {
        self.dateProvider = dateProvider
    }
    
    func makeMessage() -> String {
        let now = Int(dateProvider.now.timeIntervalSince1970)
        return "\(now) - Hello."
    }
}

En complément, le modèle Arrange-Act-Assert apporte la structure pour définir la valeur des Test Double et l’état initial. On peut aussi s’appuyer sur les méthodes de teardown pour faire un nettoyage après chaque test.

S : Self-validating ✅

Chaque test doit être autonome pour déterminer si le résultat correspond aux attentes. Personne ne devrait intervenir. Sa sortie est simple : un test a réussi ou a échoué.

Il ne devrait pas y avoir besoin d’interprétation manuelle. Si on est amené à lire un fichier, à comparer des résultats, à chercher des informations, il y a un risque de faire une erreur humaine. C’est aussi plus long et rébarbatif, ce qui pourrait décourager les développeurs de lancer les tests.

Un test ne devrait pas non plus nécessiter d’action manuelle, ni avant le lancement, ni après. Il ne faut pas avoir à intervenir pour préparer un environnement ou nettoyer des artefacts, par exemple. Si un tel besoin est présent, il faut l’automatiser ou l’intégrer dans le test.

Solutions

Avec les outils actuels, les tests respectent globalement déjà ce principe. Il suffit d’ajouter une assertion dans un test pour qu’il puisse valider lui-même le résultat ; le framework et l’outillage s’occupe du reste. L’assertion la plus basique est une déclaration indiquant que quelque chose doit être vrai.

Les frameworks de tests proposent en général plusieurs méthodes d’assertion : assert true, assert not null, assert equal, assert throw exception, etc. Au moins l’une de ces instructions doit être présente dans un test.

L’interprétation du résultat des tests peut s’améliorer avec des solutions plus visuelles. Certains frameworks et IDE proposent des interfaces graphiques listant les tests et mettant en valeur les succès et les échecs.

En ce qui concerne l’automatisation pour éviter une intervention manuelle, là encore l’injection de dépendance et la structure Arrange-Act-Assert sont utiles. En préparant et simulant un environnement spécifique pour un test, par exemple.

T : Timely ⏱

Un test doit être écrit au bon moment. Idéalement, le test est écrit juste avant le code de production qui fera réussir le test. Ce mode opératoire apporte de réels bénéfices et fait la différence. De cette manière, on avance par plus petits bouts et on se concentre sur l’essentiel. Les tests, déjà écrits, nous aident et nous guident. On voit émerger le design du code.

À l’opposé, écrire les tests après le code de production comporte des risques. L’ajout de tests a posteriori est plus long et plus difficile. Cela nécessite un travail supplémentaire : il faut souvent adapter le code de production qui n’est pas testable. Ce travail est parfois conséquent et coûteux. Plus on éloigne l’écriture des tests, plus ce risque sera grand.

Outre la difficulté, la motivation peut baisser lorsqu’il s’agit d’écrire des tests lorsque l’on a terminé. Un sentiment de culpabilité peut également naître en pensant au temps supplémentaire à passer pour ajouter des tests et adapter le code de production alors que tout est déjà prêt.

Solutions

Commencer par écrire un test fait partie de l’approche Test-Driven Development (TDD). Le développement est guidé par les tests. On est guidé pour implémenter le comportement par petites étapes. Suivre cette pratique, c’est suivre un cycle précis : RED, GREEN, REFACTOR.

Pour faire simple, on écrit d’abord un test qui échoue ou ne compile pas : c’est rouge. On cherche ensuite à passer au vert en écrivant le minimum de code de production, en allant au plus simple. Puis on refactorise, on améliore le code de production et le code des tests. La boucle est bouclée, alors on recommence. On itère jusqu’à ce qu’on ait répondu au besoin et qu’on soit satisfait du code.