Mini-test — ION/Algosys — Christian Desrosiers : TDD et évolution du logiciel

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.

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.

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.

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.

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.

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.

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.