Extrait de la newsletter TLDR Web Dev du 27 août 2025,

React-is-Awful

An AI generated book about React that teaches React and humorously complains about its complexity and design decisions.

Cette courte description a piqué ma curiosité autant pour le côté généré par IA que sur le fond avec un petit bonus pour la plainte humoristique.

Dès le README du dépôt git, le ton est donné :

What You'll Learn

• ❌ Why it exists (Facebook's notification counter was sometimes wrong)
• ❌ The Virtual DOM (a solution to a problem React created)
• ❌ JSX (HTML and JavaScript had a baby nobody asked for)
• ❌ Hooks (functions that remember things, breaking everything functions stand for)
• ❌ useEffect (the footgun you'll shoot yourself with)
• ✅ How to get a job anyway

et ce ton humoristique voire sarcastique se poursuit tout au long du livre et rend sa lecture très amusante ce qui est quand même rare dans un livre technique.

Cet ouvrage a donc, a priori, été généré par une IA générative (Claude) et si ce n'était pas précisé dès le départ, je suis pas certain que je l'aurais remarqué en le lisant. Il y a certes quelques tournures et enchaînements qui semblent un peu maladroits mais on en trouve aussi dans des livres écrits par des humains. Je serais quand même curieux de voir le ou les prompts qui permettent d'obtenir ce résultat.

Sur le fond, le livre vise plutôt juste dans ses critiques de React (en tout cas cohérentes avec ma propre expérience) et dans ses préconisations pour faire avec. Et contrairement à ce que pourrait suggèrer le titre, le livre reconnaît tout de même quelques mérites à React. Il n'y a guère que le chapitre sur les tests qui, certes, pointe un problème réel mais mériterait sans doute un peu plus de nuances. En vrai, ce chapitre pourrait faire l'objet d'un livre entier à lui tout seul 🫠

Bref, React-is-Awful est à la fois un ovni dans le paysage des livres techniques et un bon ouvrage pour approfondir la compréhension de React et des compromis que son usage impose.

Je commence donc par le premier qui me vient à l'esprit que j'aime bien exprimé avec la citation suivante attribuée à Antoine de Saint-Exupéry :

La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer.

En d'autres termes, je déclare la chasse au superflu ouverte 😃 En pratique, qu'est ce que cela signifie ?

L'application la plus évidente de ce principe consiste à éliminer ce qu'on appelle le code mort (dead code). Il s'agit sans doute de l'un des code smells les plus connus qui désigne le code qui ne peut pas être atteint. Équipé·e d'un bon IDE, de quelques outils d'analyse statique et de bons tests automatisés, il est relativement facile de le détecter et de l'éliminer au niveau d'une fonction ou d'un fichier. En revanche, au niveau d'un projet conséquent avec un peu d'historique (comprendre du code legacy 😜) c'est une autre histoire. Petite anecdote, il y a quelques mois, sur deux projets TypeScript j'ai poussé pour essayer de rationaliser l'usage du mot clé export en introduisant un script dans la CI pour détecter les changements qui incluent des export inutilisés (basé sur ts-unused-export) et pour progressivement éliminer les export inutilisés existants. Cette démarche s'inscrivait déjà dans une volonté de chasser le superflu mais mon but initial était surtout de faciliter le refactoring (sans mot clé export, on est certain d'avoir un périmètre limité au fichier) et au final, cet exercice a permis de déterrer une quantité de code mort plus que conséquente (plusieurs milliers de lignes de code 😮) qui n'était là que être exporté sans être utilisé et qui occasionnait de la confusion et zéro valeur ajoutée. Hop un peu moins de dette technique !

Si on prend un peu de hauteur, appliquer ce principe dans le design d'une API (d'une simple méthode comme d'une API web type REST ou GraphQL) est un bon outil pour s'éviter un peu de complexité. Par exemple, si une méthode accepte des paramètres optionnels mais qu'ils ne sont jamais utilisés ou que cette méthode reçoit un paramètre avec toujours la même valeur ou que sa valeur de retour n'est jamais utilisée vous avez probablement du superflu sous les yeux qui induit une certaine complexité et qui aurait tout intérêt à être éliminé pour améliorer la maintenabilité. On parle parfois de réduire la surface d'API. L'exercice est assez mécanique et d'autant plus simple si on l'applique à la création du code en question. Pour ce qui me concerne, c'est le genre de chose que je fais au fil de l'eau et que je vérifie dans une revue de code.

Si on prend encore un peu plus de hauteur, ce principe s'applique aussi très bien à l'ajout de toute fonctionnalité. Dit autrement, il est toujours intéressant de questionner la solution vis à vis du besoin qu'on cherche à satisfaire pour systématiquement en tirer l'essentiel et surtout en retirer tout le reste. Dans ce contexte, cette démarche permet de restreindre autant que possible le périmètre des changements et encore une fois de réduire la complexité mais également de permettre de se concentrer sur l'essentiel et d'obtenir un résultat satisfaisant le plus rapidement possible et, à partir de là, d'itérer jusqu'à atteindre une solution qui apporte suffisamment de valeur. Toute ressemblance avec l'un des principes du manifeste agile n'est PAS fortuite 😛 :

La simplicité – c’est à dire l'art de minimiser la quantité de travail inutile – est essentielle.

Et puis cette démarche va au delà du code et des fonctionnalités, elle s'applique par exemple très bien au workflow des développeur·ses. Qui n'a jamais subi un workflow (CI, CD, commit hook,…) plus lourd que nécessaire ? Ou à toutes ces réunions qui pourraient être un simple email 🫠 Ici, il s'agit plus d'un potentiel problème d'efficacité au quotidien mais là encore le superflu peut peser lourd.

Bref, sans surprise, identifier et chasser le superflu est un exercice bénéfique pour la qualité d'un projet logiciel et la productivité des développeur·ses. Plus qu'une simple habitude, pour moi, cette démarche doit être active et systématique. Je la considère comme une clé dans l'obtention d'un code maintenable sur le long terme et dans l'efficience au quotidien.

Dans le numéro de JavaScript Weekly de la semaine dernière, on trouve notamment Dynamic GitHub profile with Bun and Typescript où l'auteur explique comment il personnalise et surtout rend dynamique son profil GitHub. Cet article m'a rappelé que j'avais dans mes brouillons un billet sur le même sujet et comme j'utilise une approche un peu différente, c'est l'occasion de le terminer de parler un peu de la plomberie l'envers du décor.

La personnalisation d'un profil GitHub est simple à mettre en place, il suffit de créer un dépôt nommé comme votre nom d'utilisateur username/username et d'y ajouter un fichier README.md à la racine pour que son contenu soit repris sur le profil. Pour moi, le README.md de https://github.com/dpobel/dpobel se retrouve sur la page profile, ce qui donne quelque chose comme :

Il reste donc à mettre à jour régulièrement ce fichier pour que le profil affiche des informations à jour. Dans mon cas, en plus d'une courte introduction, je souhaite afficher les derniers billets publiés sur ce site ainsi que quelques billets sélectionnés. Comme l'auteur de l'article cité plus haut, je pourrais mettre un peu de code dans le dépôt username/username et lancer régulièrement un script via GitHub Actions (ou autre) pour mettre à jour le README.md à partir de flux RSS. Néanmoins, je vois au moins deux inconvénients dans cette approche (qui a quand même le mérite d'une certaine simplicité) :

1. il faut nécessairement ajouter du code dans le dépôt username/username ce qui implique un peu de maintenance
2. l'action de mise à jour doit être configurée pour s'exécuter régulièrement quelque soit l'activité sur ce site, compte tenu des hauts et des bas des publications par ici, ce n'est probablement pas une utilisation de ressources très efficace 😉

Par ailleurs, au moment où j'ai voulu mettre en place cette personnalisation, j'avais un besoin proche qui consistait à également tenir à jour https://dpobel.github.io/ en fonction de l'activité ici. Là encore, j'aurais pu mettre un peu de code dans le dépôt correspondant pour construire une page ce qui aurait occasionné les mêmes inconvénients.

Bref, en cherchant une alternative, j'ai découvert que GitHub expose une API REST qui permet notamment de déclencher un workflow GitHub Actions offrant ainsi une manière d'éliminer le second inconvénient. À partir de là, j'ai réalisé que je pouvais facilement ajouter dans la construction de ce site la génération du README.md pour le dépôt username/username et d'une page HTML destinée à https://dpobel.github.io/ et qu'ensuite à l'issue du déploiement, il suffisait de déclencher un workflow GitHub Actions par API pour chacun de ces dépôts qui peuvent se contenter de télécharger un fichier et de le commiter. De cette manière, l'essentiel de la logique est concentré dans la construction de ce site qui pilote les mises à jour externes.

Pour résumer la recette de ma potion magique 🧙 :

1. générer le README.md sur son site pour qu'il soit déployé avec le reste (ou le rendre disponible à une URL connue si vous utilisez un CMS dynamique)
2. Configurer un workflow GitHub Actions pour télécharger ce fichier et le commiter sur le dépôt username/username
3. sur un évènement par exemple au déploiement ou si vous utilisez un CMS sur la publication d'un nouveau contenu, faire un appel API pour déclencher ce workflow.

Et hop la magie opère ✨️ La même mécanique est à l'œuvre pour la mise à jour de https://dpobel.github.io/. Si j'en crois l'historique des commits du dépôt pour le profil et de celui de la page, la magie opère depuis un peu plus de 3 ans sans quasiment aucune intervention manuelle sur ces dépôts.

Si vous écrivez des tests en JavaScript / TypeScript, il est plus que probable que vous ayez déjà croisé les fonctions describe et it . En effet, les frameworks de test les plus populaires comme Jest, Mocha ou encore Jasmine s'inspirent tous de RSpec et mettent à disposition ces fonctions pour écrire et structurer les suites de tests. Dans sa documentation, Mocha désigne cette API l'interface BDD.

Un autre pratique courante pour structurer le code d'un cas de test est d'utiliser des commentaires pour séparer les différentes étapes du test notamment le triptyque Given, When, Then (inspiré de BDD encore) ou son équivalent souvent abrégé AAA: Arrange, Act, Assert. Par exemple :

describe('MyComponent', () => {
  const sut = new MyComponent();

  it('should do stuff when the input is something', () => {
    // Given
    const input = buildSomeInput();

    // When
    sut.doStuff(input);

    // Then
    expect(sut).toHaveDoneSomething();
  });
});

Ces commentaires peuvent être une aide pour structurer son code mais comme d'habitude, ils sont une bonne occasion de se demander si il n'est pas possible de rendre le code plus expressif et spoiler alert, c'est le sujet de cet article 😉

On peut déjà remarquer que la ligne après Given est la mise en place de l'état indiqué par when the input is something dans l'intitulé du test. Également, quelque soit le framework de test utilisé, describe est non seulement une API pour grouper des cas de tests mais cette fonction offre aussi la possibilité d'utiliser des hooks notamment pour déclencher des actions avant chaque cas de test ou avant tous les tests inclus dans ce describe. Donc en combinant une bonne description (le premier paramètre de describe) par exemple commençant par given et un hook on obtient un code plus expressif qui incorpore ce commentaire Given et lui associe le comportement correspondant. Reste When et Then, mais sont ils bien utiles ? Systématiquement When sera destiné à la première ligne du cas de test et vraisemblablement Then à tout le reste…

En d'autre termes, l'exemple ci-dessus peut-être réécrit de la manière suivante :

describe('MyComponent', () => {
  const sut = new MyComponent();

  describe('given the input is something', () => {
    let input;

    beforeEach(() => {
      input = buildSomeInput();
    });

    it('should do stuff', () => {
      sut.doStuff(input);

      expect(sut).toHaveDoneSomething();
    });
  })
});

Évidemment sur un exemple aussi simple, la différence est minime mais sur des suites de tests combinant plusieurs états ce pattern s'avère particulièrement pratique, par exemple imaginons un composant dont la responsabilité est de notifier un utilisateur en fonction de son profil et d'une configuration, la suite de tests pourrait ressembler à :

describe("Notifier", () => {
  const sut = new Notifier(/* some dependencies */);

  describe("given the user is a free user", () => {
    beforeEach(() => {
      // … setup the user as a free user
    })

    it("should not notify the user", () => {
      // …
    });
  })

  describe("given the user is a premium user", () => {
    beforeEach(() => {
      // … setup the user as a premium user
    })

    describe("given she has configured the notifications to be issued by SMS", () => {
      beforeEach(() => {
        // … setup user's notification to sms
      })

      it("should notify the user by sms", () => {
        // …
      });
    });

    describe("given she has configured the notifications to be issued by email", () => {
      beforeEach(() => {
        // … setup user's notification to email
      })

      it("should notify the user by email", () => {
        // …
      });
    });
  })
});

Cette structuration offre plusieurs avantages :

1. le couple systématique describe("given …") / beforeEach introduit une forme de cohésion, il est facile de voir si le hook implémente réellement la description ou à l'inverse de comprendre ce qu'implique la pré-condition ;
2. la suite de tests est facile à faire évoluer, par exemple si demain une nouvelle configuration permet d'envoyer des notifications par Slack ou tout autre moyen, il suffit d'ajouter un bloc describe et le tour est joué ;
3. en lançant le test, on obtient une spécification du composant testé (en fonction du reporter utilisé), dans cette exemple, quelque chose comme :

   Notifier
     given the user is a free user
       ✔ should not notify the user
     given the user is a premium user
       given she has configured the notifications to be issued by SMS
         ✔ should notify the user by sms
       given she has configured the notifications to be issued by email
         ✔ should notify the user by email
   

   ce qui s'avère bien pratique pour comprendre une base de code existante ;
4. lorsqu'un test échouera, la structure a toutes les chances de faciliter la compréhension de l'erreur et avec un peu de chance de faciliter l'identification du bug.

Et j'en oublie probablement !

En bref, l'utilisation de describe et de ses hooks permet de structurer les tests. Cette structure impose notamment d'isoler et surtout de nommer correctement les différents états ce qui rend les tests plus lisibles et maintenables à relativement peu de frais en s'éloignant de quelques antipatterns courants ou au contraire pour essayer d'écrire de bons tests.

Je suis tombé aujourd'hui sur Quality is systemic de Jacob Kaplan-Moss que je trouve particulièrement juste.

Traduction rapide du premier paragraphe :

La qualité logicielle est plus le résultat d'un système conçu pour produire de la qualité et pas tellement le résultat de performances individuelles. C'est-à-dire : un groupe de programmeurs médiocres travaillant avec une structure conçue pour produire de la qualité produira un meilleur logiciel qu'un groupe de programmeurs fantastiques travaillant dans un système conçu pour d'autres objectifs.

En d'autres termes pour obtenir de la qualité il faut une organisation construite pour la produire. L'auteur donne quelques exemples de caractéristiques systémiques permettant de produire de la qualité :

• une organisation et une culture qui permettent et encouragent l'écriture de bons tests ;
• une culture qui ne pousse pas à mettre en production du code qui n'est pas prêt ou qui est inutile ;
• une cadence de développement qui permet de correctement architecturer le code et de le documenter ;
• un environnement de travail où les personnes se sentent en sécurité et n'hésitent pas à demander de l'aide au besoin ;
• une culture où les échecs sont analysés sans chercher de coupable et où le système est amélioré pour éviter les échecs similaires.

Je trouve ce dernier point particulièrement important. À titre personnel c'est quelque chose que je m'attache à toujours faire mais j'ai vu relativement peu d'organisations où c'était une démarche systématique.

Et il existe probablement des tas d'autres paramètres comme une culture qui permet une forme d'auto-organisation et offre une certaine liberté, une organisation où on ne travaille que sur un seul sujet à la fois ou encore une culture qui célèbre autant voire plus la suppression de code que l'ajout… Tout ceci fait largement écho à Maximiser l'efficacité des développeur·ses sous un angle plus… systémique.

En début d'année, j'ai lu Get Your Hands Dirty on Clean Architecture (Second Edition) de Tom Hombergs. Comme son titre l'indique, ce très bon livre traite de la Clean Architecture et plus particulièrement de l'architecture hexagonale. Tout au long des quelques 140 pages, l'auteur aborde ce type d'architecture sous différents aspects mais il en est un qui revient régulièrement tout en étant le sujet du premier chapitre : la maintenabilité.

Une bonne partie de ce premier chapitre peut se résumer par cette expression pseudo-mathématique :

maintenabilité >>> tout le reste

Dans tout le reste rentrent les qualités qu'on cherche souvent à atteindre dans la construction d'un logiciel par exemple les performances, la scalabilité, la robustesse, la flexibilité et bien d'autres… Et comme l'explique très bien l'auteur, la maintenabilité a ceci de spécial qu'elle est une qualité qui permet d'atteindre toutes les autres. En effet, dès qu'un logiciel est maintenable, il est facile à faire évoluer pour atteindre certaines qualités dès que le besoin émerge. Évidemment, l'ajout de fonctionnalités et la correction des bugs sont également d'autant plus simples que le code est maintenable. En d'autres termes, la maintenabilité aide à la fois à atteindre des objectifs fonctionnels et non fonctionnels.

Je formule généralement cette idée de la manière suivante :

Un bon code est un code facile à changer.

Ni plus, ni moins. Jusque là, rien de très original je crois mais ça va mieux en le disant 😁

Dans ce chapitre, Tom Hombergs pousse la réflexion un peu plus loin et notamment en énonçant ce qui m'apparaît maintenant comme un corollaire :

Whenever we have to decide between multiple options, we can choose the one that makes the code easier to change in the future. No more agonizing between different options. We just take the one that increases maintainability the most.

ce qui peut se traduire par :

Chaque fois que nous devons choisir entre plusieurs options, nous pouvons choisir celle qui rendra le code plus facile à changer dans le futur. Plus besoin de se torturer l'esprit entre différentes options. Nous choisissons simplement celle qui augmente le plus la maintenabilité.

Quand j'ai lu cette partie, je dois dire qu'une petite lumière s'est allumée dans ma tête 💡 J'ai beau être convaincu de l'importance de la maintenabilité depuis de nombreuses années maintenant, je n'avais jamais considéré cette qualité comme une aide à la décision de manière aussi directe. Et forcément, en regardant un peu dans le rétroviseur, je me rends compte qu'appliquer ce principe dans certaines décisions aurait potentiellement mener à de meilleurs choix.

Comme souvent avec ce genre de principe général, il s'agit d'un élément parmi beaucoup d'autres et comme l'indique Tom Hombergs, le bon choix n'est parfois pas celui qui améliore ou conserve la maintenabilité. Néanmoins opter pour ce principe par défaut me semble être une bonne approche.

Et si on les jetait à l'eau refactorisait ? 😀

Dans une revue de code ou en explorant une base code, ces noms là, tout comme dans une certaine mesure les handlers et autres managers, déclenchent systématiquement dans ma tête une petite alarme 🔔 qui appelle à aller regarder de plus près ce qui se cache derrière.

Ces termes sont très génériques même si ils sont souvent accompagnés d'un préfixe, d'un suffixe ou d'un chemin un peu spécifique (encore qu'on a tous dû tomber au moins une fois sur un src/utils.js quand ce n'est pas src/tools/utils.js 😉). Et par conséquent, la ou les responsabilités de ces composants sont loin d'être claires. D'ailleurs, ce genre de composant a une sérieuse tendance à être un fourre-tout avec beaucoup plus qu'une unique responsabilité.

Aussi, quand ce genre de composant occupe une place importante dans le code en terme de quantité de logique, c'est autant de logique qui n'est pas là où elle aurait plus de sens. L'utilisation abusive de ce genre de composant va de pair avec d'autres code smells, notamment :

• des objets anémiques : les objets métiers se retrouvent dépourvus de comportement puisqu'il est relégué dans ces helpers et utils ;
• un manque d'encapsulation : les objets exposent nécessairement plus qu'ils ne devraient pour que ces composants puissent faire leur travail ;
• des abstractions manquantes : là encore, une responsibilité qui pourrait être proprement isolée dans un composant bien nommé se retrouve diluée.

C'est pourquoi, en ce qui me concerne, chaque mention d'un utils ou d'un helper me rend plus que méfiant. Quasiment systématiquement il existe une meilleure solution en terme d'expressivité, de qualité de code et de maintenabilité.

J'ai écrit un petit blabla sur le tout neuf Developers blog de Front-Commerce (oui on a pas vraiment fait dans l'originalité 😉) sur quelques défis lié à l'édition d'un logiciel destiné à être intégré par rapport à d'autres contextes comme le service ou la distribution en SAAS.

Traduction libre de l'introduction:

Pour l'essentiel, Front-Commerce est un logiciel destiné à être intégré par des développeurs pour qu'un marchand puisse vendre des produits à ses clients dans une boutique en ligne à son image et même en s'appuyant sur une infrastructure existante. S'il s'agit probablement de la définition la plus simple de Front-Commerce (plus ou moins celle que j'utilise pour décrire mon travail à ma famille et mes amis 😉), elle cache néanmoins un certain nombre de défis au quotidien.

La suite va vous étonner est disponible dans Some challenges of being the editor of a software intended to be integrated (en anglais).

Les tests pas lancés automatiquement

Une suite de tests qui n'est pas lancée automatiquement ne sert (quasiment) à rien. Bien sûr, si on se lance dans un effort pour écrire des tests (en particulier des tests end to end ou fonctionnels), cet état peut être transitoire le temps d'investir suffisamment de temps pour automatiser l'ensemble mais clairement il faut essayer d'en sortir le plus rapidement possible sinon arrivera invariablement le moment où un·e développeur·se cassera quelque chose sans s'en rendre compte et généralement, il faut pas longtemps 😉

Dans cette catégorie, il arrive aussi qu'une partie des tests ne soient pas lancer automatiquement, par exemple lors de l'ajout de code dans un endroit pour lequel le test runner n'est pas configuré. C'est assez vicieux et pas forcément évident à détecter; on peut éventuellement surveiller l'évolution du taux de couverture et/ou jeter un œil à un rapport de couverture.

Les tests superficiels

ce rapport de bug est surprenant, on a un test qui vérifie exactement ce comportement
[quelques minutes plus tard…]
aaah reproduit, le test ne vérifiait rien en fait 😠

Écrire des tests c'est bien, écrire des tests qui vérifient réellement un comportement c'est encore mieux. Par exemple, imaginons que vous vouliez tester une API HTTP plus ou moins RESTful qui permette de créer une entité quelconque avec une requête POST et qui lorsque tout se passe bien renvoie une réponse 201. Si les tests de cette fonctionnalité se contentent de ne vérifier que le statut HTTP ou quelques trucs dans le contenu de la réponse, eh bien vous avez un test (très) superficiel, il ne teste que quelques détails et passe à côté de la fonctionnalité principale qui pourrait très bien être complètement cassée sans que le test supposé la couvrir n'échoue. Bon c'est mieux que rien mais ça donne un faux sentiment de sécurité.

Pour valider la qualité et la précision des tests, il est possible d'employer une technique appeler Mutation testing. Il s'agit en quelques sorte de tester les tests en introduisant artificiellement des bugs pour vérifier sur les tests échouent, si ce n'est pas le cas, vous avez probablement des tests superficiels !

Les tests flaky

ptet bien que oui, ptet bien que non

-- un test flaky

Le grand classique des tests qui échouent seulement de temps à autre sans raison apparente. Ce type de problème peut être particulièrement compliqué à diagnostiquer et plus les tests sont de haut niveau plus le nombre de dépendances augmentent et avec elles les risques de flakyness.

Parfois, c'est beaucoup plus simple qu'il n'y paraît. Pour l'anecdote, il m'est déjà arrivé de subir des échecs aléatoires de tests en raison d'une mauvaise utilisation de rand() dans des fixtures qui n'avaient de toute manière aucune raison d'être aléatoires.

Malheureusement sur cet aspect, il n'y a pas de solution magique. Je dirais que le principal est de surveiller activement ce genre de comportement et surtout ne pas laisser la situation s'enliser car les choses auront plutôt tendance à empirer qu'à se résoudre d'elles-mêmes.

Les tests difficiles à interpréter car trop verbeux

Ah je crois que les tests sont en train d'échouer… Ah non en fait, ah je sais pas, c'est normal d'avoir 3000 lignes sur la sortie après une minute d'éxécution sur la CI ?

-- un·e dévéloppeur·se proche de la noyade

Ce problème est assez typique des tests avec du code en JavaScript, il faut dire que les méthodes console.log et consorts sont tellement faciles d'accès, qu'elles finissent par être utilisées avec un peu trop de zèle au moindre cas limite. La sortie des tests finit par être un joyeux bazar au point que parfois il devient difficile de savoir si les tests passent ou échouent. Jest propose une option --silent mais pour moi cela s'apparente plus à mettre la poussière sous le tapis qu'à résoudre le soucis. Dans un monde idéal, les tests devraient être silencieux et si quelque chose n'est pas correct, ils devraient juste échouer; oui, prop-types c'est quoi que je regarde en fronçant les sourcils !

Les tests incompréhensibles car rédigés avec des termes inconnus

Entretien d'embauche :

• nous on fait du DDD et on a des tests en mode BDD
• super, vous mettez l'accent sur la qualité, où est ce que je signe ?

En réalité, c'était l'un des plus gros mensonges de ma carrière professionnelle… Il y avait vaguement une approche DDD technique ou tactique et oui des tests écrits en Gherkin mais sans l'aspect comportement ni la plupart du temps le moindre bout de domaine et je parle pas de l'implémentation des phrases…

Bref, qu'on fasse du BDD ou non, en lisant les tests, le ou la développeur·se doit pouvoir comprendre ce que fait le composant/la fonction/l'API testée et comment elle est supposée être utilisée. C'est pourquoi le nommage doit être particulièrement soigné. Il est aussi évident que les tests sont des bouts de code qui vont nécessiter de la maintenance. Dans ces conditions appliquer les principes de clean code est plus que jamais une bonne idée que votre futur·e vous appréciera sans aucun doute.

Les tests qui échouent avec un message d'erreur cryptique

En contrôlant la verbosité et en soignant le nommage, on évite pas mal d'écueils à ce niveau. Malgré tout, lorsqu'on écrit des tests, il faut toujours avoir à l'esprit que le but est qu'ils échouent en communiquant clairement le problème. Par exemple, si vous utilisez les assertions de PHPUnit, il est plus que probable que vous devriez penser à utiliser le paramètre optionnel $message pour améliorer cet aspect. Toujours avec PHPUnit, l'utilisation de data provider permet généralement de tester rapidement un grand nombre combinaisons mais dans ce cas, bien nommer chaque combinaison améliorera grandement la compréhensibilité d'un éventuel échec et en bonus devoir trouver un nom à chaque combinaison, vous forcera peut-être à simplifier votre API et/ou à détecter des cas qui n'ont aucun sens dans votre domaine.

Les tests qui mockent l'Univers

Un grand classique d'une stratégie de tests pas vraiment réfléchie du genre tout doit être testé unitairement et/ou d'un peu trop d'attention portée au taux de couverture. En soit, il est normal de mocker les dépendances d'un composant que l'on souhaite tester unitairement. Néanmoins, si le composant en question a beaucoup de dépendances et/ou des dépendances qui proviennent d'autres projets, il est clair que le test risque d'être pénible à maintenir et pire, il pourrait même être un frein au refactoring et à l'évolution du composant testé ! Pour éviter cela, deux solutions complémentaires :

1. D'un côté, on peut considérer que le composant en question nécessite un refactoring pour diminuer le nombre de dépendances (avec autant de dépendances il est probable qu'il ait un peu trop de responsabilités) et pour s'abstraire des dépendances que l'on ne contrôle pas, l'idée étant de tendre vers une architecture hexagonale ou en oignon.
2. On peut aussi opter pour des tests de plus haut niveau comme des tests d'intégration ou fonctionnels pour éviter de tout mocker et tester un peu moins unitairement chaque composant. Le prix à payer est une mise en place des tests potentiellement un peu plus complexe et éventuellement un peu moins de couverture (certains cas limites peuvent être plus difficiles à obtenir) mais en contrepartie ces tests seront plus simples et surtout à partir du moment où la fonctionnalité est couverte, on peut la retravailler en tout sérénité et éventuellement se lancer dans le refactoring évoqué précédemment.

Comme toujours en développement, c'est une affaire de contexte, de compromis et de stratégie.

Les tests interdépendants

Je comprends pas, j'ai changé 3 détails dans une méthode et j'ai 30 tests qui échouent dans les tests fonctionnels de l'API REST

-- Un·e développeur·se devant un château de cartes qui s'effondre

Alors bien sûr il est possible de faire échouer beaucoup de tests avec peu de changements mais la dernière fois où je me suis trouvé en face de cette situation la raison était un peu différente. J'avais effectivement introduit un bug dans la création d'une entité quelconque ce qui aurait du faire échouer 3 tests mais en fait les 27 autres assumaient que ces premiers tests passaient pour utiliser les données créées… une belle manière de rendre les choses confuses. J'ai aussi vu des suites de tests ou certains tests en appellent directement d'autres voire même issues d'une autre suite de tests ! Là encore, c'est l'effet château de cartes au moindre bug.

Tout ceci est du vécu ; heureusement pour ma santé mentale, j'ai jamais vu de projet qui cumulait tous ces antipatterns, après j'ai aussi vu pas mal de projets critiques sans aucun test 😀

Plus sérieusement, tous ces défauts ne sont pas seulement agaçants, ce sont surtout des obstacles pour travailler efficacement et pour produire un logiciel robuste et de qualité ce qui est quand même un comble pour une technique justement supposée améliorer ces aspects.

useEncapsulation or Why Your React Components Should Only Use Custom Hooks par Kyle Shevlin donne une excellente explication :

[…] These custom hooks give us a little more context to what they mean, and we don't have the implementation details of our state handler functions sitting in the middle of our component function.

que je traduis grossièrement par :

[…] Ces hooks sur-mesure donnent un peu plus de contexte sur leur signification et permettent de ne pas mélanger leurs détails d'implémentation avec la fonction qui sert de composant.

ou autrement dit, cette approche permet de séparer la logique purement d'affichage de la logique disons métier (même si les exemples sont simplistes) à laquelle il est obligatoire de donner un nom. Le bénéfice est immédiat : une bien meilleure lisibilité.

Ce n'est pas mentionné dans l'article, mais en bonus cette approche donne l'opportunité de tester unitairement cette logique métier et d'éventuellement laisser de côté l'affichage (ou de le tester différemment) et également de pouvoir composer d'autres composants avec cette même logique.

Dernier point, quand je regarde ce hook sur-mesure :

function useInput(initialState = '') {
  const [state, setState] = React.useState(initialState)

  const handlers = React.useMemo(
    () => ({
      handleInputChange: e => {
        setState(e.target.value)
      },
      resetInput: () => {
        setState(initialState)
      },
    }),
    [initialState]
  )

  return [state, handlers]
}

Même si cette fonction renvoie un tableau, je dois dire que j'y vois ni plus ni moins qu'une structure avec les méthodes pour la manipuler, c'est à dire quelque chose qui ressemble sérieusement à… un objet au sens de la programmation orientée objet ! Ce qui est plutôt ironique pour une approche qui se veut fonctionnelle 😇