Entraînement — ION/Algosys — Christian Desrosiers : TDD et évolution du logiciel

Le petit exemple rend observable la succession besoin, test, échec, implémentation et amélioration du code. Cette discipline peut servir à faire évoluer un logiciel durable. La simplicité de la fonction ne prouve cependant ni la couverture d’un produit entier ni un gain chiffré transposable à toute entreprise.

• Identifier le mécanisme de construction et de vérification.
• Limiter les conclusions tirées de la taille du programme.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

Une expérience avec peu d’options permet de confronter des hypothèses de besoin et de solution à un résultat concret. Le pont représente dans l’analogie une décomposition plus connue; le service innovant apprend en avançant. Cela justifie petits pas et rétroaction, sans prétendre que toute construction est prévisible ou que tout logiciel échappe à la planification.

• Tester des hypothèses par une expérience limitée.
• Distinguer compliqué et complexe dans la portée de cette analogie.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

Après cinq minutes, l’auteur possède encore le contexte et peut corriger avant diffusion. Six mois plus tard peuvent s’ajouter soutien, reproduction, recherche du changement, rechargement du contexte et nouvelle livraison, avec un impact client. Il faut donc compter toute la chaîne, sans convertir l’exemple en multiplicateur universel.

• Comparer disponibilité du contexte et diffusion du problème.
• Inclure soutien, reproduction, enquête et livraison au-delà du codage.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

Vérifier la cible appelée, les données et l’assertion, puis déterminer si le comportement existe déjà. Un échec significatif établit ce qui manque : écrire le minimum pour le vert, refactorer si une amélioration est utile et rejouer la suite. Le refactoring n’est pas une transformation obligatoire à chaque tour; un rouge réel ne garantit pas non plus la richesse des données. Un bogue de production reproductible peut aussi devenir un test rouge avant correction, puis une protection automatique contre son retour.

• Diagnostiquer le vert prématuré plutôt qu’ajouter du code sans besoin.
• Rouge significatif → minimum au vert → refactoring utile et vérification.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

L’isolation aide à diagnostiquer un aspect et fournit un retour rapide; l’intégration teste les branchements et comportements réels que les simulations ne prouvent pas. Faire passer les contrôles rapides avant les niveaux coûteux évite de gaspiller ces exécutions sur une erreur déjà visible. Cette organisation n’impose pas une architecture en microservices.

• Distinguer isolation et intégration réelle.
• Exécuter les tests rapides d’abord sans supprimer les niveaux plus larges.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

La conférence attribue directement ce changement à la généralisation et à la productisation, même si le TDD a soutenu la qualité et l’évolution dans le récit. Le résultat dépend du produit, des pratiques et du contexte. Il faut distinguer amélioration observée, mécanisme annoncé et promesse causale sur un autre projet.

• Attribuer le gain direct de 2025 à la productisation.
• Refuser la causalité unique et la garantie de transfert à une autre équipe.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

Ces tests caractérisent le comportement et peuvent figer une erreur; l’exigence sert à juger sa justesse. Pour faire évoluer l’existant, protéger les changements, pratiquer le TDD sur le nouveau travail et extraire les zones gênantes lorsque nécessaire permet une amélioration proportionnée. Avoir des tests après coup ne rend pas rétroactivement le développement TDD et n’impose pas une réécriture globale.

• Distinguer caractérisation et conformité au besoin.
• Protéger les changements et améliorer proportionnellement, sans réécriture automatique.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

Le premier cas ne distingue pas une constante d’un traitement de l’entrée. Joseph fait échouer cette constante et demande de construire la salutation à partir du nom. Il faut conserver les protections déjà testées pour null et vide; ajouter deux noms ne démontre pas le comportement pour tous les cas atypiques.

• Joseph doit faire échouer la constante.
• Construire depuis l’entrée et conserver les attentes existantes.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

La CI apporte une information sur l’intégration; la capacité de livraison et le contrôle d’activation sont d’autres étapes. L’usine conserve ses contraintes de disponibilité, de réseau et d’installation. Il faut organiser la mise en service selon ce contexte : un switch ne livre pas lui-même une version et un vert ne décide pas du calendrier client.

• Distinguer intégration, livraison/installation et activation.
• Prendre en compte les contraintes opérationnelles du client.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

Le résultat visible ressemble au robinet qui coule; il ne montre pas la qualité des tuyaux. Lire structure, dépendances et tests permet d’évaluer le risque d’un changement ultérieur. L’expérience sert à guider et vérifier le travail assisté; ce retour de conférence n’est ni un benchmark universel des outils ni une permission d’IA dans les évaluations du cours.

• Examiner structure, dépendances et protections de tests.
• Relier ces contrôles au coût et au risque des changements futurs.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

La productisation permet de configurer des besoins auparavant programmés pour chaque client. Écrire ces personnalisations plus vite ne décrit pas ce changement de mode; une réduction de périmètre n’est pas l’explication donnée. Le TDD a soutenu l’évolution dans le récit, sans être la cause directe unique de ce gain.

Variantes : Une seule réponse. Comparer le raisonnement au corrigé après avoir répondu.

L’automatisation ne fournit pas l’exigence qui manque. Le test caractérise ce que fait le code; un attendu copié d’un bogue peut protéger ce bogue. Il faut une référence au besoin pour décider si un changement est une correction ou une régression.

Variantes : Une seule réponse. Comparer le raisonnement au corrigé après avoir répondu.

Les exceptions pour null et vide, puis les salutations pour Gontrand et Joseph sont les quatre cas démontrés. Les noms longs et caractères atypiques sont évoqués sans être implémentés : mentionner une idée de test ne signifie pas l’avoir exécutée.

Variantes : Une seule réponse. Comparer le raisonnement au corrigé après avoir répondu.

Il faut comprendre ce que le test observe. Il peut viser une mauvaise cible, mal affirmer le résultat ou couvrir un comportement déjà présent. Fabriquer un échec ou refactorer sans ce diagnostic ne démontre pas la détection du comportement manquant.

Variantes : Une seule réponse. Comparer le raisonnement au corrigé après avoir répondu.

Séparer les aspects observables dans des scénarios nommés permet de voir quels comportements échouent sans les masquer derrière le premier arrêt. Chaque test doit préparer son propre état sans dépendre d’un précédent. Ce n’est pas un quota universel d’une seule assertion : plusieurs assertions cohérentes peuvent décrire le même aspect.

• Découper par aspect observable avec des noms utiles.
• Préparer chaque scénario indépendamment de l’ordre d’exécution.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

Le mock impose un résultat contrôlé pour observer la composante cible. Le test ne visite ni le calcul réel de la dépendance ni tous les branchements réels. Un contrôle d’intégration pertinent doit exercer cette collaboration; remplacer encore plus de dépendances par des mocks ne fournit pas cette preuve.

• Limiter la conclusion au comportement isolé testé.
• Vérifier la collaboration des composants réels par intégration.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

Le Setup factorise la construction, mais TestInitialize doit créer une nouvelle instance avant chaque test. Cela garde un point de modification du constructeur tout en évitant de partager l’état mutable entre scénarios. Initialiser une fois pour toute la suite ne procure pas cette indépendance.

• Créer une nouvelle instance avant chaque test.
• Factoriser la préparation sans partager l’état mutable.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

Les lignes de données ne changent ici ni l’action ni l’attendu : le test répète Gontrand. Passer le paramètre à DitBonjour et construire l’attendu correspondant fait réellement exercer Joseph. Une réponse constante doit alors échouer pour Joseph; le nombre de lignes seul ne prouve pas la diversité testée.

• Faire alimenter l’appel par chaque DataRow.
• Faire varier l’attendu avec l’entrée pour détecter la constante.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

L’acceptation exprime le résultat fonctionnel recherché. Les cycles unitaires construisent et diagnostiquent les composants, mais il reste à les intégrer jusqu’à satisfaire ce résultat extérieur. Un vert local n’est donc pas un motif pour supprimer le test d’acceptation en échec; les deux niveaux apportent des informations différentes.

• Acceptation : résultat métier extérieur.
• Cycles unitaires : construction des composants, puis intégration jusqu’au résultat attendu.

Variantes : Répondre avant d’ouvrir le corrigé; comparer ensuite les critères essentiels à votre raisonnement. Aucun score automatique sur le texte.

Le premier scénario demande ArgumentNullException pour null. Le second ajoute ArgumentException pour la chaîne vide et doit conserver la réussite du premier. Les deux entrées ne sont donc pas traitées comme une salutation vide. La démonstration n’étend pas cette preuve aux noms atypiques seulement évoqués.

Variantes : Une seule réponse.

Les catégories décrivent l’usage et son destinataire : organiser son propre travail, construire le logiciel, ou fournir une capacité au client dans le produit. Elles ne constituent ni un inventaire des fonctions déjà livrées ni une mesure de gains. Les propos professionnels de la conférence ne modifient pas la règle d’IA du cours.

Variantes : Une seule réponse.

Non : le contrôle ne vérifie ici que le contenu selon sa configuration, alors que le besoin porte aussi sur l’ordre. Il faut une assertion qui compare la séquence dans l’ordre attendu. Choisir une méthode d’assertion par son nom ou l’autocomplétion sans vérifier sa signification peut masquer cette divergence. Le scénario donne explicitement la règle du contrôle, sans supposer l’API d’un framework particulier.

• Identifier la différence entre le besoin ordonné et le contrôle sans ordre.
• Vérifier la séquence attendue plutôt que seulement ses éléments.

Variantes : Comparer le raisonnement aux critères essentiels; formulations équivalentes recevables, sans notation automatique du texte.