Interlude - conformité de base

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : J. B. Rainsberger
Source : Interlude: Basic Correctness
Date : 2009


Traducteur : Fabrice Aimetti
Date : 07/09/2011


Traduction :

J'ai essayé de répondre à un commentaire de James Bach, mais j'ai dépassé la limite des 3000 caractères, donc j'ai décidé de publier ce long commentaire sous la forme d'un court article.
James Bach : Je ne comprends pas pourquoi vous baptisez de "injustifiable" un échec découvert lors de l'exécution d'un test. Je vous donne une raison très simple : JE VEUX TROUVER DES BUGS. :)
J.B. Rainsberger : S'il vous plaît, changer la définition que j'ai donné pour un mot n'est pas très fair-play. Arrêtez ça ! :)

James Bach : Quand vous énoncez "Nous aurons vraisemblablement des tests dont le but est de tester l'étape 2, et qui échoueront bien sûr de façon justifiée" (NdT : article 3ème partie - Les risques associés aux tests trop longs), cela me semble être une dangereuse supposition. Ce n'est pas parce que nous écrivons un test, et que ce test a un but, que cela signifie que le test atteint son but. En fait, pour autant que je sache, un test n'atteint JAMAIS son but le plus profond à savoir de trouver tous les bugs possibles et intéressants dans le bout de code qu'il est train de tester. Bien sûr, quand je teste, je veux trouver tous les bugs intéressants, et bien sûr, je ne saurai jamais si j'ai trouvé tous ceux qui valaient le coup.
J.B. Rainsberger : Je pense que vous avez repris ma définition spécifique de "l'échec justifiable" et que vous l'avez étendue bien au-delà de la manière dont j'avais choisi de l'utiliser. Quand j'écris un test qui échoue en raison d'une anomalie dans le code pour lequel le test était dédié, alors je baptise cet échec justifiable. Tous les autres échecs ne sont pas justifiables. Par conséquent, l'énoncé que vous avez mis en avant est implicite pour moi ... mis à part mon usage imprécis du mot "vraisemblablement". Permettez-moi de clarifier ce que je n'ai pas exprimé. Supposons que nous avons utilisé des tests d'intégration pour tester globalement ce processus en cinq étapes (en d'autres termes, nous avons écrit des tests pour trouver au minimum toutes les anomalies de conformité de base). Cela signifie que nous avons écrit certains tests pour vérifier plus particulièrement l'étape 2. Supposons maintenant l'existence d'une anomalie uniquement à l'étape 2. Quand notre test échoue à l'étape 4 en raison d'une anomalie à l'étape 2, les tests de l'étape 2 échouent de façon justifiée, alors que les tests de l'étape 4 échouent de façon injustifiée. Je n'ai pas encore tourné mon attention sur les anomalies latentes et cachées, pour la raison que je fournirai à la fin de ce commentaire.
James Bach : ... C'est pourquoi j'utilise une stratégie de test différente. Il me semble que des tests d'intégration complexes qui couvrent un maximum du code - également couvert par d'autres tests - constitue une stratégie raisonnable, aussi longtemps que ce n'est pas trop coûteux à produire ou à maintenir. Il y a un rapport coût/bénéfice qui doit être évalué par rapport au coût d'opportunité, bien entendu.
J.B. Rainsberger : Je suis d'accord, mais je vois trop souvent des développeurs (en particulier) utiliser les tests d'intégration pour les aider à trouver ou éviter des anomalies alors que des tests isolés sur des objets, qui sont beaucoup moins coûteux, les aideraient justement mieux à trouver ou éviter ces anomalies. Je fonde mon entière argumentation sur l'hypothèse que beaucoup de développeurs utilisent ces tests d'une manière qui mène à un considérable gaspillage en efforts de maintenance.
James Bach : Donc, peut-être que vous parlez d'un contexte restreint où cela ne vaut pas le coup de tester une fonction particulière indirectement. Peut-être que ce n'est pas le cas, mais je parie qu'il est utile de prendre en considération ce type de tests. Personnellement, j'aime bien les tests automatisés qui touchent beaucoup de choses à beaucoup d'endroits, tant que je peux les créer et les maintenir sans perturber la sagacité de mes testeurs humains.
J. B. Rainsberger : Effectivement ! J'ai voulu révéler ces différents points de façon graduelle afin d'éviter de pondre 20000 mots d'un coup, mais j'ai limité les arguments de cette série d'articles à un contexte spécifique : les développeurs écrivent des tests pour montrer la conformité de base de leur code. Par conformité de base je me réfère au mythe de la technologie parfaite : si je lance le système sur une technologie parfaite, calculera-t-il (finalement) la bonne réponse à chaque fois ? Je baptiserais un tel système de fondamentalement et totalement conforme. Alors que les tests d'intégration ont une réelle valeur dans d'autres contextes, les développeurs les utilisent trop souvent pour démontrer la conformité de base, et quand ils font cela ils gaspillent une quantité énorme de temps et d'effort.