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 !

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.