Jusqu’à l’AFUP Day 2024, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

TDD : principe, architecture synergique, types et stratégie de tests Le code produit pour une application est rarement celui qu'on avait prévu de prime abord. De plus, ce code va dans la plupart des cas évoluer au fil du temps et des changements du besoin. Les tests unitaires permettent de s'assurer de la non régression du code sur les fonctionnalités existantes. Le TDD permet de se servir de cette possibilité pour en plus itérer sur de petites unités de code et pour découvrir son architecture au fil du développement. Au travers d'un exemple en PHP, nous verrons d'abord le principe du TDD et ses avantages. Nous aborderons ensuite le principe de l'architecture hexagonale pour voir en quoi celle-ci permet au TDD de fonctionner à son plein potentiel. Enfin, nous reverrons les types de tests à notre disposition et nous verrons en quoi l'utilisation de ces différents types nous permet de développer le code le moins sujet à bugs possible.

I.U.T. Nancy-Charlemagne 24/05/2024 16:20-17:00

Est-ce que le TDD peut vraiment s’appliquer à chaque projet ?

Le TDD permet d’obtenir le plus petit code nécessaire pour les besoins du business. Une fois maîtrisé, il permet d’avoir un même résultat effectif, avec une base de code souvent plus simple et une suite de tests qui servent de documentation des décisions business appliquées. Sachant cela, le TDD peut s’appliquer sur n’importe quel projet, car il permet d’avoir un résultat plus rapide et de meilleure qualité. 2 nuances cependant :

– Sur un projet de type CRUD pur, le TDD est inutile, car il n’y a pas de règles métier, mais une simple transposition de données dans une interface. Dans ce cas, on peut même se poser la question d’un développement, là où des outils « out of the box » fourniront le même résultat en quelques fichiers de configuration. Attention toutefois, souvent, on considère comme un « simple CRUD » un jeu d’opérations qui ont de plus en plus de règles business, on n’est donc plus dans le « simple CRUD », ou on n’y sera plus d’ici quelques temps.

– Travailler en TDD nécessite de comprendre les outils dont on se sert. Travailler en TDD pour faire des tests d’intégration sur une technologie que l’on ne maîtrise pas va être inefficace et fastidieux, car on ne sait pas vraiment quoi tester, comment le tester, ou pourquoi on n’obtient pas le résultat attendu.

Après avoir travaillé longtemps en solo, quel conseil donnerais-tu à quelqu’un qui commence à collaborer dans des équipes de développement plus grandes ?

Quand on a travaillé depuis longtemps en tant que dev en solo, l’arrivée en équipe va être une source d’inquiétudes. Le syndrome de l’imposteur est démultiplié par le manque de retour de ses pairs, et on ne voit que les éléments qui pourraient nous manquer.

Ce qu’on arrive moins à voir dans ces cas-là, ce sont les points forts d’une personne ayant travaillé en solo. Le/la dev solo a généralement eu à travailler un peu au-delà du cadre « standard » du dév, devant un peu travailler sur l’administration du serveur, un peu sur le SEO des projets clients, un peu de product management. La personne arrive donc avec une vision un peu élargie des processus de travail.

De la même façon, le /la dev solo a généralement dû se débrouiller seul. Il a forcément eu, comme tous les dévs, des moments où il bloquait, où il ne savait pas, où il ne comprenait pas. Mais à l’inverse d’un·e dev en équipe, il n’a pas pu demander de l’aide à ses collègues, réfléchir ensemble, avoir des points de vue extérieurs. De ce fait, il aura appris à se débrouiller seul. Arrivée en équipe, la personne pourra probablement plus facilement travailler de manière indépendante et se débrouiller dans son nouveau contexte.

Comment votre transition vers les principes de clean architecture et de tests unitaires a-t-elle impacté votre approche de développement au sein du secteur médical ?

Le secteur médical impose des normes de développement et de déploiement que d’autres secteurs n’ont pas nécessairement.

La clean architecture nous permet de scinder le code métier et le code d’implémentation technique. Cela permet d’avoir des tests (unitaires ou autres) plus clairs car découpés. Nous avons moins de « gros » tests end to end où la préparation du cas de test est longue et rend celui-ci peu compréhensible et plus sujet à casser aux moindres modifications. Les tests de métier permettent de tester des intentions de notre métier de manière plus simple, plus claire et peuvent servir de documentation lorsqu’un comportement est à vérifier.

Dans le but d’obtenir les certifications relatives aux normes, la clean architecture nous permet d’avoir plus facilement un cahier de test à fournir à chaque certification que l’on génère automatiquement, depuis les tests que nous avions de toutes façons à créer, ce qui allège le travail nécessaire pour l’audit liée à la norme.

Une conférence présentée par

Jean-Pascal LANGINIER

Jean-Pascal développe sur PHP depuis 12 ans. Il a travaillé sur plusieurs CMS et Frameworks, longtemps en solo. Après avoir découvert les principes de clean architecture et de tests unitaires d'intention, il a pris en main ces sujets et les met désormais en application au sein d'une entreprise éditrice d'une solution SaaS dans le secteur médical.

Autres intervenants