Pour qui

• Développeuses et développeurs C# et .NET qui écrivent peu ou pas de tests, ou qui en écrivent sans conviction
• Équipes qui veulent installer le TDD comme pratique commune, pas comme initiative individuelle

Prérequis

• Pratique quotidienne de C# et de l'écosystème .NET
• Un environnement installé : Visual Studio 2022 Community ou Rider
• Aucune expérience préalable des tests automatisés n'est nécessaire

Objectifs

• Choisir le bon type de test (unitaire, intégration, bout en bout) selon ce qu'il doit protéger
• Reconnaître un bon test et une bonne suite de tests : rapide, fiable, déterministe, lisible
• Rendre du code testable par l'injection de dépendances, sans tout réécrire
• Pratiquer le TDD en cycle red, green, refactor sur une fonctionnalité réelle
• Poser un filet de tests sur un code existant avec la méthode Golden Master, puis le refactorer en sécurité

La plupart des équipes savent qu’il faudrait des tests. Beaucoup en ont écrit quelques-uns, puis ont arrêté : trop lents, trop fragiles, cassés à chaque refactoring, et personne ne sait plus s’ils protègent quelque chose. Le problème n’est presque jamais l’outil. C’est ce qu’on teste, à quel moment, et à quelle profondeur.

Cette formation prend le sujet dans l’ordre : comprendre ce qu’un test protège, écrire les premiers avec les outils de l’écosystème .NET, puis apprendre à reconnaître un bon test d’un mauvais sur ceux que vous venez d’écrire. Le deuxième jour, on passe au TDD, en groupe, sur une fonctionnalité qui résiste. Le troisième jour, facultatif, s’attaque au cas qui fait peur : le projet qui existe déjà et qui n’a jamais été pensé pour être testé.

À quoi vous attendre

La qualité d’un test dépend surtout du moment où on l’écrit. Une bonne partie de la formation consiste à faire l’expérience de cette différence.

Le programme tient sur deux journées de sept heures, avec une troisième en option. Les journées peuvent être consécutives ou espacées d’une semaine, pour laisser le temps d’appliquer les contenus entre deux séances.

• On écrit des tests dès la première matinée. La théorie sert à choisir, pas à attendre. Chaque concept est suivi d’une mise en pratique sur du code.
• On critique ses propres tests. L’après-midi du premier jour repart des tests écrits le matin par les participants pour en tirer les critères d’un bon test.
• Le TDD se pratique en mob programming. Un clavier, un écran, tout le groupe. C’est la manière la plus rapide de faire passer une pratique de « j’ai compris » à « je le fais ».
• Le jour legacy se fait sur votre code si vous le voulez. Le formateur fournit un projet, mais un extrait de votre propre application est un bien meilleur terrain.

Les exemples sont en C# avec xUnit, Reqnroll et Playwright. En intra-entreprise, la formation existe aussi en TypeScript et en PHP.

Programme

Jour 1 : écrire des tests, puis apprendre à les juger

Matin. Introduction aux tests automatisés

• Ce qu’un test automatisé protège, et ce qu’il ne protège pas
• Les familles de tests : unitaires, d’intégration, d’acceptation, de bout en bout
• Les approches : tests passants et non passants, boîte blanche et boîte noire
• Les trois familles qui concernent les développeurs au quotidien : unitaires, intégration, bout en bout

Matin. Première mise en pratique

• Prise en main de xUnit et de la structure Arrange, Act, Assert
• Tester le même code de plusieurs manières pour sentir ce que chaque famille apporte
• Tour d’horizon des outils de l’écosystème .NET : xUnit, Reqnroll pour les scénarios, Playwright pour le bout en bout
• Atelier : écrire une première suite de tests sur un code fourni

Après-midi. Ce qui fait un bon test

• À partir des tests écrits le matin : lesquels sont rapides, fiables, déterministes, lisibles, et pourquoi
• Les caractéristiques d’une bonne suite de tests, au-delà de chaque test pris isolément
• Où porter son attention quand on met en place une suite de tests dans une équipe
• Atelier : réécrire les tests du matin à la lumière de ces critères

Après-midi. Architecturer son code pour qu’il soit testable

• Pourquoi certains codes sont impossibles à tester : couplage, dépendances cachées, état global
• Cohésion et couplage comme critères concrets, pas comme principes abstraits
• L’injection de dépendances comme levier de testabilité, sur des exemples puis sur du code réel
• Atelier : rendre testable un morceau de code qui ne l’est pas

Jour 2 : convaincre, puis pratiquer

Matin. Défendre les tests devant son équipe et sa hiérarchie

• À partir des observations de la veille : les gains des tests à court, moyen et long terme
• Construire un argumentaire qui parle de valeur livrée, pas de pureté technique
• Point d’étape sur ce qui a été retenu, particulièrement utile quand les deux journées ne sont pas consécutives

Matin. La temporalité des tests

• Le même programme, les mêmes tests, écrits avant, pendant ou après le code
• Comparer les résultats : ce qui change dans la conception, dans la couverture, dans la lisibilité
• Atelier en groupes suivi d’une restitution croisée

Matin. Questions et réponses

• Reprise des concepts abordés, à la demande des participants
• Lever les doutes restants avant de passer au TDD

Après-midi. La pratique du TDD

• Le cycle en trois temps : red, green, refactor
• Découper une fonctionnalité complexe en problèmes simples, dans un ordre qui fait émerger la conception
• Écrire le minimum de code qui satisfait la contrainte du moment
• Ajouter des tests jusqu’à couvrir toutes les contraintes du domaine
• Atelier en mob programming : tout le groupe, sur une seule fonctionnalité, jusqu’à la solution complète

Jour 3, en option : poser un filet de tests sur du legacy

Cette journée s’adresse aux équipes dont le projet principal n’a pas été conçu pour être testé. Y insérer des tests est difficile sans méthode. On en repart avec une boîte à outils de techniques éprouvées.

Elle peut se dérouler sur un code fourni par le formateur ou, de préférence, sur un extrait de votre propre projet.

Matin. Refactorer un code legacy avec la méthode Golden Master

• Capturer un instantané du comportement actuel de l’application, tel qu’il est, bugs compris
• Poser des tests qui vérifient que cet instantané ne change pas
• Modifier la structure du code sous ce filet, pour augmenter sa testabilité
• Vérifier à chaque étape que le comportement est préservé
• Atelier : mettre un module sous Golden Master puis le refactorer

Après-midi. Techniques de refactoring d’un code existant

• Les code smells qui empêchent de tester : ce qu’ils sont, comment les repérer en lecture
• Les refactorings qui les corrigent, un par un, et comment les enchaîner sans casser
• Rendre l’exécution déterministe : dates, aléatoire, appels externes, état partagé
• Atelier : dérouler la boîte à outils sur un code réel

Avec quoi vous repartez

• Une suite de tests écrite par vos soins, et critiquée par le groupe
• La fonctionnalité développée en TDD, commit par commit, pour retrouver le cheminement
• Pour le jour legacy : un module de votre code sous filet de tests, et la liste des techniques employées
• Un argumentaire pour défendre les tests là où vous travaillez

Organiser cette formation

Elle se donne dans vos locaux, pour votre équipe, sur votre code si vous le souhaitez. Le programme s'adapte à votre contexte et à votre langage.

Me contacter par emailouMe contacter sur LinkedIn