Interlude - conformité de base - Historique des versions

Fabrice Aimetti le 17 août 2018 à 21:18

Fabrice Aimetti — Fri, 17 Aug 2018 21:18:57 GMT

← Version précédente		Version du 17 août 2018 à 21:18
Ligne 2 :		Ligne 2 :
	[[Category: J. B. Rainsberger]]		[[Category: J. B. Rainsberger]]
	[[Category: Tests]]		[[Category: Tests]]
	~~<div id="content_view" class="wiki" style="display: block">~~ Auteur : J. B. Rainsberger<br /> Source : [http://www.jbrains.ca/permalink/interlude-basic-correctness Interlude: Basic Correctness]<br /> Date : 2009<br />		Auteur : J. B. Rainsberger<br />
			Source : [http://www.jbrains.ca/permalink/interlude-basic-correctness Interlude: Basic Correctness]<br />
			Date : 2009<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 07/09/2011<br />		Traducteur : Fabrice Aimetti<br />
			Date : 07/09/2011<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">''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.''</span><br /> <span style="display: block; text-align: justify">'''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. :)</span><br /> '''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 ! :)<br /> <br /> <span style="display: block; text-align: justify">'''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%C3%A8me%20partie%20-%20Les%20risques%20associ%C3%A9s%20aux%20tests%20trop%20longs\|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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span>		Traduction :<br />
			<br />
			<span style="display: block; text-align: justify">''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.''</span><br /> <span style="display: block; text-align: justify">'''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. :)</span><br /> '''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 ! :)<br /> <br /> <span style="display: block; text-align: justify">'''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%C3%A8me%20partie%20-%20Les%20risques%20associ%C3%A9s%20aux%20tests%20trop%20longs\|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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span>

Fabrice Aimetti le 14 juillet 2018 à 06:44

Fabrice Aimetti — Sat, 14 Jul 2018 06:44:52 GMT

← Version précédente		Version du 14 juillet 2018 à 06:44
Ligne 6 :		Ligne 6 :
	Traducteur : Fabrice Aimetti<br /> Date : 07/09/2011<br />		Traducteur : Fabrice Aimetti<br /> Date : 07/09/2011<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">''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.''</span><br /> <span style="display: block; text-align: justify">'''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. :)</span><br /> '''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 ! :)<br /> <br /> <span style="display: block; text-align: justify">'''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%C3%A8me%20partie%20-%20Les%20risques%20associ%C3%A9s%20aux%20tests%20trop%20longs 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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span>		''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">''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.''</span><br /> <span style="display: block; text-align: justify">'''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. :)</span><br /> '''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 ! :)<br /> <br /> <span style="display: block; text-align: justify">'''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%C3%A8me%20partie%20-%20Les%20risques%20associ%C3%A9s%20aux%20tests%20trop%20longs\|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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span>

Fabrice Aimetti le 14 juillet 2018 à 06:44

Fabrice Aimetti — Sat, 14 Jul 2018 06:44:24 GMT

← Version précédente		Version du 14 juillet 2018 à 06:44
Ligne 1 :		Ligne 1 :
	[[Category: Portail Equipe de développement]]		[[Category: Portail Equipe de développement]]
	[[Category: J. B. Rainsberger]]		[[Category: J. B. Rainsberger]]
			[[Category: Tests]]
	<div id="content_view" class="wiki" style="display: block"> Auteur : J. B. Rainsberger<br /> Source : [http://www.jbrains.ca/permalink/interlude-basic-correctness Interlude: Basic Correctness]<br /> Date : 2009<br />		<div id="content_view" class="wiki" style="display: block"> Auteur : J. B. Rainsberger<br /> Source : [http://www.jbrains.ca/permalink/interlude-basic-correctness Interlude: Basic Correctness]<br /> Date : 2009<br />
	----		----

Fabrice Aimetti le 6 juillet 2018 à 08:05

Fabrice Aimetti — Fri, 06 Jul 2018 08:05:54 GMT

← Version précédente		Version du 6 juillet 2018 à 08:05
Ligne 1 :		Ligne 1 :
	[[Category: Portail Equipe de développement]]		[[Category: Portail Equipe de développement]]
	[[Category: J.B. Rainsberger]]		[[Category: J. B. Rainsberger]]
	<div id="content_view" class="wiki" style="display: block"> Auteur : J. B. Rainsberger<br /> Source : [http://www.jbrains.ca/permalink/interlude-basic-correctness Interlude: Basic Correctness]<br /> Date : 2009<br />		<div id="content_view" class="wiki" style="display: block"> Auteur : J. B. Rainsberger<br /> Source : [http://www.jbrains.ca/permalink/interlude-basic-correctness Interlude: Basic Correctness]<br /> Date : 2009<br />
	----		----

Fabrice Aimetti le 6 juillet 2018 à 08:05

Fabrice Aimetti — Fri, 06 Jul 2018 08:05:43 GMT

← Version précédente		Version du 6 juillet 2018 à 08:05
Ligne 1 :		Ligne 1 :
	[[Category: Portail Equipe de développement]]		[[Category: Portail Equipe de développement]]
	[[Category: J.B. Rainsberger]]		[[Category: J.B. Rainsberger]]
	<div id="content_view" class="wiki" style="display: block"> Auteur : ~~[/J.%20B.%20Rainsberger~~ J. B. Rainsberger]<br /> Source : [http://www.jbrains.ca/permalink/interlude-basic-correctness Interlude: Basic Correctness]<br /> Date : 2009<br />		<div id="content_view" class="wiki" style="display: block"> Auteur : J. B. Rainsberger<br /> Source : [http://www.jbrains.ca/permalink/interlude-basic-correctness Interlude: Basic Correctness]<br /> Date : 2009<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 07/09/2011<br />		Traducteur : Fabrice Aimetti<br /> Date : 07/09/2011<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">''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.''</span><br /> <span style="display: block; text-align: justify">'''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. :)</span><br /> '''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 ! :)<br /> <br /> <span style="display: block; text-align: justify">'''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%C3%A8me%20partie%20-%20Les%20risques%20associ%C3%A9s%20aux%20tests%20trop%20longs 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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span>		''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">''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.''</span><br /> <span style="display: block; text-align: justify">'''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. :)</span><br /> '''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 ! :)<br /> <br /> <span style="display: block; text-align: justify">'''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%C3%A8me%20partie%20-%20Les%20risques%20associ%C3%A9s%20aux%20tests%20trop%20longs 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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span><br /> <span style="display: block; text-align: justify">'''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.</span>

Fabrice Aimetti : Page créée avec « Category: Portail Equipe de développement Category: J.B. Rainsberger
Auteur : [/J.%20B.%20Rainsberger... »

Fabrice Aimetti — Fri, 06 Jul 2018 08:05:32 GMT

Page créée avec « Category: Portail Equipe de développement Category: J.B. Rainsberger <div id="content_view" class="wiki" style="display: block"> Auteur : [/J.%20B.%20Rainsberger... »

Nouvelle page

[[Category: Portail Equipe de développement]]
[[Category: J.B. Rainsberger]]
<div id="content_view" class="wiki" style="display: block"> Auteur : [/J.%20B.%20Rainsberger J. B. Rainsberger] Source : [http://www.jbrains.ca/permalink/interlude-basic-correctness 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%C3%A8me%20partie%20-%20Les%20risques%20associ%C3%A9s%20aux%20tests%20trop%20longs 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.

Interlude - conformité de base - Historique des versions

Fabrice Aimetti le 17 août 2018 à 21:18

Fabrice Aimetti le 14 juillet 2018 à 06:44

Fabrice Aimetti le 14 juillet 2018 à 06:44

Fabrice Aimetti le 6 juillet 2018 à 08:05

Fabrice Aimetti le 6 juillet 2018 à 08:05

Fabrice Aimetti : Page créée avec « Category: Portail Equipe de développement Category: J.B. Rainsberger Auteur : [/J.%20B.%20Rainsberger... »

Fabrice Aimetti : Page créée avec « Category: Portail Equipe de développement Category: J.B. Rainsberger
Auteur : [/J.%20B.%20Rainsberger... »