La version extrêmement courte: des tests plus petits, car ils exécutent de plus petites parties du système, contraignent naturellement ce que les programmeurs peuvent écrire, ce qui crée une opportunité de générer des commentaires plus précis (plus faciles à remarquer / plus difficiles à ignorer). Permettez-moi d'ajouter que cela ne conduit pas nécessairement à une meilleure conception, mais plutôt à une opportunité de détecter les risques de conception plus tôt.
Premièrement, pour préciser, quand je parle de "microtest", je veux dire "un petit test" et rien de plus. J'utilise ce terme parce que je ne veux pas dire "test unitaire": je ne veux pas m'impliquer dans des débats sur ce qui constitue une "unité". Je m'en fiche (du moins pas ici / maintenant). Deux personnes s’accorderont probablement plus facilement sur «petit» que sur «unité», j’ai donc décidé peu à peu d’adopter «microtest» comme terme standard émergent pour cette idée.
Les tests plus volumineux, c'est-à-dire les tests qui exécutent de plus grandes parties du système dans leur partie "action", ont tendance à ne pas critiquer la conception de manière aussi claire ni aussi complète que des tests plus petits. Imaginez l'ensemble des bases de code pouvant passer avec succès un groupe de tests donné, ce qui signifie que je pourrais réorganiser le code et qu'il réussirait quand même ces tests. Pour de plus grands tests, cet ensemble est plus grand; pour des tests plus petits, cet ensemble est plus petit. Autrement dit, des tests plus petits contraignent davantage la conception, de sorte que moins de conceptions peuvent les faire passer. De cette façon, les microtests peuvent critiquer davantage la conception.
Je dis "plus durement" pour évoquer l'image d'un ami qui vous dit directement ce que vous ne voulez pas entendre, mais que vous devez entendre, et qui vous crie de transmettre l'urgence de manière à ce que les autres ne se sentent pas à l'aise Faire. Les tests intégrés, en revanche, restent silencieux et ne font que suggérer des problèmes, surtout lorsque vous n’avez plus le temps ni l’énergie nécessaire pour les résoudre. Des tests intégrés simplifient trop facilement les problèmes de conception.
Avec des tests plus volumineux (comme les tests intégrés), les programmeurs ont généralement tendance à avoir des ennuis: ils ont assez de liberté pour écrire du code enchevêtré qui leur permet de passer les tests, mais leur compréhension de ce code s'estompe rapidement au moment où ils passent à la tâche suivante. et d’autres ont des difficultés indues à lire le dessin enchevêtré. C’est là que réside le risque de s’appuyer sur des tests intégrés. Avec des tests plus petits (comme des microtests), les programmeurs ont généralement tendance à avoir des problèmes de spécification excessive: ils surchargent les tests en ajoutant des détails non pertinents, généralement par copier-coller à partir du test précédent, et ils se peignent eux-mêmes assez rapidement. dans un coin. Bonnes nouvelles: Je trouve qu'il est beaucoup plus facile et plus sûr de supprimer des détails superflus des tests plusieurs heures ou jours après que je les ai écrits que de séparer du code de production enchevêtré, mois après années, après l'avoir écrit. Au fur et à mesure que les erreurs disparaissent, une spécification excessive provoque des dommages de plus en plus évidents plus rapidement, et le programmeur d'alerte voit plus tôt qu'il est nécessaire de réparer le problème. Je considère cela comme une force: je remarque les problèmes plus tôt et les corrige avant que ces problèmes ne nous empêchent d’ajouter des fonctionnalités.