Le TDD est un sujet d’intérêt pour les praticiens depuis au moins une dizaine d’années, voire avant si l’on tient compte des pratiques d’eXtreme Programming et du manifeste agile.
Malgré sa popularité revendiquée aujourd’hui et son symbolisme de qualité, la pratique consistant à écrire le test avant le code de production est encore inégale. Cela varie en fonction du contexte du praticien, des expériences passées et du parcours d’apprentissage du praticien.
Nous pourrions élaborer davantage sur la connaissance inégale du TDD à partir de l’éducation formelle sur le sujet, par conséquent, cela pourrait nécessiter encore plus de discussions sur son applicabilité. Est-il possible d’enseigner efficacement le TDD sans expérience professionnelle de projet ? Certains diront que c’est possible, d’autres diront le contraire.
Malgré un excellent contenu publié par des éditeurs renommés tels que O’Reilly, packt, # Addison-Wesley Professional Computing Series, Apress et Manning, la pratique du TDD reste un défi, même les meilleurs livres, les meilleurs exemples, ne peuvent pas traduire automatiquement son contenu aux problèmes uniques auxquels les praticiens sont confrontés au quotidien.
Les katas sont un outil qui pourrait être utilisé pour combler cette lacune à la fois : la formalité dans l’apprentissage du TDD et les problèmes d’unicité auxquels les praticiens sont confrontés.
Pratiquer avec des katas n’est pas un remplacement, cela peut être compris comme une aide à la place.
L’inadéquation avec les vrais problèmes
Les praticiens ont essayé différentes approches pour internaliser le développement piloté par les tests. Malgré les efforts, l’inadéquation entre la formation et le code de production existe.
Les modèles trouvés dans la pratique des Katas sont proches des projets de terrain vierge. Au quotidien, il est fort probable que les praticiens rejoignent un projet de friche industrielle qui n’est pas très facile à entretenir. Il existe des livres qui se concentrent uniquement sur cet aspect des choses, par exemple, Working efficient with legacy code de Michael Feathers, Refactoring : Improving the Design of Existing Code de Martin Fowler, Refactoring to Patterns de Joshua Kerievsky, et bien d’autres.
Les modèles que les praticiens utilisent pour les Katas mais qui sont généralement incompatibles avec le code de production qui apparaît fréquemment ensemble sont :
- Approche pour tester de l’extérieur – quand dois-je passer à l’unité ?
- Couche persistante – J’utilise un ORM (Object Relational Mapping) ou les couches de mon application sont mélangées
Il existe différentes approches que l’on peut adopter pour écrire du code, ce qui est généralement partagé dans le code source est la technique consistant à diviser les problèmes, puis à combiner toutes les pièces pour résoudre le problème.
Plongeons-nous dans le découpage et ce que cela signifie de l’utiliser pour commencer à aborder la transition de Katas au code de production.
Regrouper
Le processus de découpage se produit sans que l’on s’en aperçoive, mais les praticiens sont des experts dans cette technique. L’approche de segmentation est décrite par Learning how to learn de Barbara Oakley et également décrite par Felienne Hermans dans son livre The programmer’s Brain.
Le processus est le même que pour un algorithme : étant donné un problème complexe, quelles sont les pièces qui composent le problème ? et quels sont les morceaux qui peuvent être divisés? A chaque pas, avancez l’aiguille pour résoudre le problème.
Diviser le problème est important, car cela permet à notre cerveau de travailler sans le surcharger, nous avons des limites à travailler avec des informations. En ce qui concerne spécifiquement les praticiens, c’est l’une des raisons pour lesquelles on peut ne pas avoir toute l’architecture du système dans sa tête, comme décrit dans What Makes A Great Software Engineer? par Paul Luo Li, Amy J. Ko et Jiamin Zhu.
En prenant du recul, si nous parlons de Katas, ils sont la première étape du découpage. Dans cette étape, nous nous concentrons (mais nous limitons) sur :
- Apprendre quelque chose de nouveau (comme la pratique d’écrire des tests en premier)
- Une compétence pointue, étant donné que le TDD est un sujet connu, on pourrait vouloir essayer différents styles. Tels que : avec ou sans doublons de test, un nouveau style architectural, un nouveau langage de programmation, etc.
Sans cette première étape, il pourrait être difficile pour les praticiens, sur le tas, d’apprendre le TDD, d’apprendre les petits pas, d’apprendre la conception simple, d’apprendre à refactoriser, d’apprendre les styles architecturaux qui pourraient correspondre au problème à résoudre, d’apprendre l’approche pragmatique d’un problème , et ainsi de suite.
Il y a beaucoup à prendre en compte, les katas en font abstraction et se concentrent sur une seule technique à portée de main. Par exemple, prenez la liste suivante (qui n’est pas exhaustive) comme point central :
- pétillement se concentre sur les pas de bébé
- mars rover se concentre sur le flux TDD
- réfrigérateur intelligent se concentre sur les tests en double
- rose dorée se concentre sur le code hérité
Les katas sont là pour faciliter le processus d’apprentissage des techniques utilisées quotidiennement par les pratiquants. Bien sûr, ce n’est que la première étape, le premier morceau qui permet aux praticiens de devenir efficaces dans leur travail.
Extension au code de production
Passer d’un cadre Kata à un projet professionnel en cours de production n’est pas aussi transparent qu’il y paraît.
Prenons en compte les projets de friches industrielles, qui sont les projets les plus susceptibles d’être rencontrés par les praticiens.
Le premier obstacle qui n’est pas facilement transporté depuis Katas est que le code peut mélanger trop de responsabilités dans une seule classe, ou qu’il y a trop de choses à comprendre du code, car c’est un développeur qui a quitté l’entreprise déjà écrit, ou les dépendances du projet sont trop nombreuses.
Quoi qu’il en soit, les défis se résument dans le projet de loi.
Pour en revenir à la segmentation, la première étape ici consiste à identifier un seul point qui peut être abordé. C’est une étape importante, car la technique est déjà en formation.
Se concentrer sur un seul aspect à la fois pour améliorer le code de production joue un rôle important.
Réfléchissons au scénario suivant :
Nous avons une application qui a été développée avec un framework MVC (modèle-Vue-Contrôle), mais les couches ont été mélangées, il n’y a pas de superposition claire en cours, à part cela, il n’y a pas de test en place, l’application est principalement testée via une approche manuelle. Pour couronner le tout, les praticiens veulent appliquer les nouvelles techniques qu’ils ont apprises pour rendre le code maintenable.
Comme nous en avons déjà discuté, le point clé ici est d’identifier d’abord les pièces du puzzle. Essayer de s’attaquer à tous les problèmes énumérés en même temps pourrait causer plus de mal que d’avantages. Énumérons les morceaux clés :
- Logique métier mixte entre les couches
- Il est difficile de lire une ligne entre les couches, ce qui conduit souvent à un test manuel de bout en bout – s’il s’agissait d’une API, cela se ferait par courrier, s’il s’agissait d’une application Web, cela se ferait en accédant au navigateur et naviguer comme le ferait l’utilisateur final.
- Il n’y a pas de test automatisé en place
- Les praticiens veulent appliquer les nouvelles techniques apprises
- Un exemple d’approche pourrait être la mise en œuvre d’un nouvel algorithme qui fonctionne plus rapidement
- Restructurer le code pour l’adapter à un style architectural
Si nous y réfléchissons un par un, nous commençons à voir une corrélation avec des Katas spécifiques que nous pourrions vouloir exécuter :
Logique métier mixte entre les couches
Rose dorée est un bon candidat pour cela, en appliquant la technique du golden master, aide à améliorer la structure interne du code.
Il n’y a pas de tests automatisés en place
Encore une fois, Rose dorée permet la création de nouveaux cas de test qui n’existent pas, comme l’étape précédente, utilisait le maître d’or, maintenant le code devrait permettre aux praticiens d’écrire de nouveaux tests qui peuvent coder des cas limites spécifiques qui n’étaient pas auparavant.
Les praticiens veulent appliquer les nouvelles techniques apprises
À ce stade, les deux étapes précédentes sont déjà en place, avec cela, le code doit être suffisamment testable pour que le code de production ne soit pas fortement couplé au code de test – Cela devrait être un bilan de santé, avant de mettre en œuvre les nouvelles techniques.
Pouvez-vous répondre à la question :
Si je refactorise, les tests ne changent pas et j’ai la confiance nécessaire pour publier ?
Si la réponse est Ouipuis appliquer les nouvelles techniques apprises devrait être faisable.