![[Home]](/wiki.jpg)
TDDUneDefinitionTDDUneDefinitionQuand vous développez, utilisez un outil de test capable de restituer un retour d'information visuel à la fin de l'exécution des tests. Utilisez soit un outil de type graphique qui affiche une BarreVerte en cas de succès et une rouge en cas d'échec, ou bien un outil de type console qui affiche "Tous les tests sont passés" ou bien une cascade de diagnostics, respectivement.
Puis exécutez chaque action de cet algorithme :
Cet algorithme suscite un peu d'interprétations. Chaque item en MAJUSCULES révèle un gisement de nuances, dont chacune est redevable à cet l'algorithme et à l'intention de chaque action. Chaque action répond à une intention différente, et entre en conflit direct avec l'intention d'une autre action. Nos comportements durant chaque action diffèrent et s'opposent. Ces modifications répétées, avec des intentions opposées, détrempent notre code d'une façon que l'on doit expérimenter pour l'apprécier pleinement et commencer à la comprendre. Suspendez votre incrédulité : essayez le cycle, et reportez vos résultats dans le AgileAlliance le plus proche.
Une "CAPACITE DU CODE", dans ce contexte, est le filon courant de charbon dans la mine, sur lequel s'élancent nos pioches. C'est l'endroit dans le programme où nous devons ajouter de nouvelles lignes, ou modifier des lignes existantes. Typiquement, cet endroit est proche du bas de notre fonction la plus récente. Si nous pouvons envisager une ligne de plus à ajouter ici, ou une modification de plus à faire ici, alors nous devons forcément être capable d'envisager le test complémentaire qui échouera sans cette en plus ou cette modification.
"ECRIVEZ UN TEST" peut signifier écrire un cas de test, et obtenir au plus une assertion. Ou bien, on peut prendre une fonction de test existante, et y ajouter de nouvelles assertions. Pour réutiliser les scenarios et les étoffer, on préfèrera cette manière.
Si les nouvelles lignes de test assument des faits qui ne sont pas évidents -- si, par exemple, ils référencent une classe ou un nom de méthode qui n'existe pas encore -- lancez tout de même le test, et prévoyez le diagnostic du compilateur. Ce test recueille des informations valides autant que tout autre. Si inexplicablement le test passe, vous comprenez maintenant que vous étiez sur le point d'écrire une classe dont le nom entre en conflit avec celui d'une classe existante.
Travaillez sur l'assertion et sur la structure du code (mais pas sur son comportement) jusqu'à ce que le test ECHOUE POUR LA BONNE RAISON. S'il passe, inspectez le code afin de vous assurer que vous le comprenez, et assurez vous que le test est passé pour la bonne raison; ensuite passez à la capacité suivante.
Tout ce travail vous prépare a faire la MODIFICATION MINIMALE. Ecrivez cette ligne que vous êtiez anxieux de sortir depuis les quatres dernier paragraphes.
La MODIFICATION est MINIMALE parce que jusqu'à ce que la Barre revienne au Vert nous vivons sur du temps emprunté. Un comportement correct et des tests paisibles sont légèrement plus importants que la qualité de notre conception. Nous pourrions faire passer le test en clônant une méthode et en y changeant une ligne. Si c'est là le nombre minimal de modifications, faites-le. Nous pourrions réécrire entièrement une méthode très similaire à une méthode existante. Ou bien, la modification la plus simple pourrait aussi produire une conception propre qui ne nécessitera aucun refactoring.
Si la MODIFICATION MINIMALE échoue, et si la raison de l'échec n'est pas évidente et simple, cliquez sur "Undo" et réessayez. Tout est préférable au débogage, et une once de prévention vaut mieux qu'une livre de remèdes.
Maintenant que nous avons une Barre Verte, nous INSPECTONS LA CONCEPTION. De par la règle de la MODIFICATION MINIMALE, le défaut de conception le plus probable est la duplication. Afin de nous aider à apprendre à améliorer les choses, nous étendons autant que possible la définition de "duplication".
Le livre Design Patterns enseigne que nous améliorons une conception lorsqu'en abordant l'interface, nous "faisons abstraction de ce qui varie". C'est une manière inversée de dire "fusionner la duplication de qui ne varie pas". Donc si nous commençons par une MODIFICATION MINIMALE, fusionner ensemble ce qui est dupliqué tendra à nous rapprocher d'un Pattern.
Pour REAMENAGER, nous inspectons le code, et essayons d'envisager une conception faite avec moins de parties mobiles, moins de duplication, des méthodes plus courtes, de meilleurs identifiants, et des abstractions plus profondes. Démarrez avec le code que l'on vient juste de changer, et n'hésitez pas à impliquer tout autre code présent dans le projet.
Si nous ne pouvons pas envisager une conception meilleure, nous pouvons tout de même procéder à l'étape suivante. Identifiez les MODIFICATIONS MINIMALES qui soit amélioreront la conception, soit mèneront à une série de modifications similaires conduisant à une amélioration. Entre chaque modification, lancez tous les tests. S'ils échouent, cliquez "Undo" et recommencez.
Le niveau de propreté est important ici. Vous pouvez avoir une qualité de code qui autrefois aurait passé pour "suffisante". Ou bien vous pouvez vous passionner pour quelqu'abstraction nouvelle que le code pourrait utiliser, peut-être dans quelque mois, ou peut-être dans quelques minutes. Laissez tomber. Le cheminement de la bidouille vers de nouvelles fonctionnalités est toujours plus difficile que celui de l'élégance vers de nouvelles fonctionnalités. Réglez les problèmes, y compris tout code spéculatif, tant que ceux-ci sont petits.
Nous pouvons ajouter des assertions à pratiquement n'importe quel moment; pendant le REFACTORING de la conception, ou avant de procéder à la capacité suivante. A chaque fois que nous apprenons quelque chose de nouveau, ou que nous réalisons qu'il y a quelque chose que nous ne savions pas, nous saisissons cette opportunité pour écrire de nouvelles assertions qui expriment ce qui a été appris, ou qui interrogent les capacités du code. Pendant que s'opère le cycle TDD, et que les fonctionnalités individuelles s'aditionnent, nous prenons le temps de recueillir à partir du code des informations à propos de ses paramètres d'exécution courants, et de ses conditions-limites.
Les conditions-limites sont la frontière entre le comportement défini et les régions ou pourraient vivre des bugs. Placez les limites d'une routine bien au delà de la portée connue du code de production qui l'appellera. Faites des recherches sur la "Conception par Contrat" pour apprendre de bonnes stratégies; celles-ci déploient des portées définies de comportements depuis les routines de bas niveaux vers les routines appellantes. A l'intérieur d'une routine donnée, simplifier son corps supprimera le plus souvent des discontinuités dans sa réponse.
Typiquement, des paramètres inclus dans ces limites conduiront le code à répondre en douceur, avec des variations linéaires. La probabilité de bogues se présentant dans les limites est typiquement plus faible que partout ailleurs. Par exemple il est improbable que la méthode qui aujourd'hui accepte 2, 3 ou 5 et retourne 10, 15, ou 25 respectivement, acceptera 4 et répondra 301 demain. Comme les substitutions algébriques qui réduisent une expression, la suppression des redondances écarte les cas spéciaux.
Maintenant qu'une fonction est créée, d'autres fonctions vont l'appeler. Leurs tests engagent aussi notre fonction. Nos tests couvrent chaque instruction d'un programme, et ils s'approchent d'une couverture totale des chemins d'un programme. La pression accumulée contre les bugs rend ceux-ci extraordinairement improbables.
Si votre code fait quelque chose d'inattendu, ou que vous recevez un rapport de bug, ECRIVEZ UN TEST, toujours. Puis utilisez ce que vous avez appris pour améliorer la conception, et écrivez plus de tests de cette catégorie. Si vous traitez la situation "Ce code ne possède pas encore cette fonctionnalité" en tant qu'une sorte de bug, alors le cycle TDD n'est rien d'autre qu'une spécialisation de la régle "Chasser les bugs par les tests".
Phlip ( http://www.c2.com/cgi/wiki?TestFirstUserInterfaces )
DeleteMoi?: http://groups.google.fr/groups?q=The+book+/Test+Driven+Development/+says&hl=fr&lr=&ie=UTF-8&oe=UTF-8&selm=SiqJa.3116%24Tn.2157%40newssvr31.news.prodigy.com&rnum=1
dubious translations items (english word then french word choosen (other words considered) )
--ct
"to refactor" should be the standard French jargon that has emerged.
"code ability" just means "smaller than a requirement, feature, or task". One or two lines of code.
Merci. Mais la technique n'aide pas le code existant ("legacy code").
Le terme important est le changement, pas la capacité.