Dans la plupart des entreprises que j’ai croisés, on retrouve la même politique de livraison rapide.
Il faut délivrer coute que coute sans se préoccupper de l’avenir.
Voila comment j’y répond.
A l’origine de cette vision on retrouve toujours des préoccupations business ou des croyances selon lesquelles :
- le quick & dirty c’est pas si mal
- on aura le temps d’écrire la doc ou les tests plus tard
- il faut satisfaire le client d’abord
Les problèmes que ces croyances impliquent sont nombreux.
- La doc n’est jamais écrite ou si elle existe, n’est pas consultée … on a tellement l’habitude qu’il n’y en ait pas qu’on ne pense plus à aller voir.
- Les tests ne sont jamais écrits et encore moins lancés. Une feature demandée par le client aura toujours la priorité sur la partie technique.
- On conserve une codebase mal écrite (car rapidement), mal adaptée, composée de rustines et de bout de ficelles
- Les temps de developpement s’allongent pour des choses simples
- On ose plus toucher cette partie du code car elle fonctionne mais les gens qui ont travaillé dessus sont pârtis sans laisser de mode d’emploi
- … j’en passe
Vous allez me dire mais que faut-il faire ?
Je n’ai pas LA solution mais j’applique la mienne partout ou je passe.
Elle tient en 3 lettres TDD pour Test Driven Development.
En bon français cela signifie le Dévelopement Piloté Par les Tests (DPPT ? 😅 ) mais on va rester sur TDD.
Et je l’applique tout le temps, quelque soit la position de la boite ou je travaille sur les tests en général.
Qu’est ce que cela implique ?
Prenons un exemple simple ou l’on vous demande de coder une feature ?
Sur cette page je voudrai cette information.
En mode quick & dirty on va s’atteler a écrire du code et rafraichir la page jusqu’a ce que le résultat soit correct.
La démarche TDD, du moins, celle que j’applique est la suivante.
Commencons par l’information.
- est ce que cette information est déjà disponible (une fonction par exemple)
Si elle existe et qu’elle est testée super !
Si elle existe sans tests.
Je commence par écrire les tests qui vont valider son fonctionnement actuel.
Cela va :
- valider que la fonction fonctionne bien comme je le voulais et en l’état.
- me rassurrer quand si je dois la modifier.
- graver ce fonctionnement dans la pierre.
C’est à dire que si quelqu’un plus tard modifie le fonctionnement de la fonction, le test devrait échouer et cela l’avertira d’un problème éventuel.
Si elle n’existe pas du tout
Premiere question à se poser : Comment je veux l’obtenir (cette information( ?
Est ce que j’écris juste une fonction dans une classe existante ?
Est-ce que je crée une classe ? un service ? un repository ?
Une fois que j’ai les idées claires sur comment je vais obtenir l’information, je commence à écrire les tests.
Je dis « les » parce que je commence généralement par les tests ou je ne peux ou je ne dois pas l’obtenir pour des raisons diverses.
Problème de droits d’accès, problèmes techniques, données invalides, ce genre de choses.
Notons que le premier test est écrit alors que je n’ai toujours rien écris sur la fonction en elle même.
Je lance l’execution de mon test qui va échouer ❌ en me disant que la fonction, la classe, le service (etc) n’existe pas… normal.
A partir de la je commence à écrire le code qui va me permettre de répondre au test d’abord de manière un peu rapide.
Cool le test passe ✅. Puis de manière plus optimisée. Tant que le test passe !
Et je vais itérer jusqu’à obtenir mon « happy path ». Toutes les conditions sont ok alors la fonction me renvoie la bonne info et tous les tests liés à cette fonction existent.
Et la restitution alors ?
Mais je ne m’arrête pas là. Ok ma fonction me renvoi la bonne info et les tests sont solides. Super.
Cependant l’info n’est toujours pas disponible sur la page demandée.
Je commence par écrire le test qui valide que cette information est bien présente sur la page demandée.
Je lance le test qui, forcément va échouer.
Je modifie ensuite la vue, le controller, etc. pour qu’il utilise la fonction écrite précédemment et que le test passe cette fois.
Mais c’est plus long non ?
La réponse est oui.
Bien sur qu’écrire le code du test + le code de la feature est plus long.
Mais !
Pas tant que ca. En pratiquant le TDD, on commence par réfléchir à comment on veut obtenir et restituer l’information.
Au lieu de travailler depuis un tableau blanc on travaille sur un texte à trou et il ne nous reste qu’a le compléter.
Avec une autre analogie c’est la différrence entre :
- un voyage ou on a seulement le départ et la destination.
- un voyage ou on a le départ, les étapes et la destination.
Le chemin est en quelque sorte balisé.
Et à moyen/long terme, les tests permettent
- de ne plus craindre la mise en production qui va tout casser
- d’avoir une base documentaire technique sur comment récupérer l’information et la restituer
- seront avertis que la modification qu’ils viennent de faire à casser quelque chose
Meme si ton employeur est contre ?
Bien (trop) souvent, l’employeur, le client, le manager n’attend que la livraison de sa feature. Il n’a aucune idée de ce que cela implique ni du pourquoi faire les tests. Il va peut etre voir qu’on va plus lentement que le/la developp.eur.se à coté mais il y a des chances pour notre code soit plus pérenne/solide et necessitent moins de hotfix sur la durée.
Le ressenti est peut etre un peu négatif sur le court terme mais à moyen, long terme il devrait s’améliorer.
Après si je code en laissant au moins des tests derrière moi je me dis que le développeur ou la développeuse qui passera après moi aura une meilleure idée de ce que j’ai fais et pourquoi. Une base documentaire sans faire de doc.
Vous l’aurez compris, quelque soit la position de mon client/manager/employeur je fais du TDD. S’il est hostile à l’idée ou qu’il prétend qu’on à pas le temps, j’en écris tout de même en pensant à mon moi futur ou à mon/ma successeur.