Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les bonnes habitudes du développement piloté par les tests
Pour un sénior, on doit obéir à trois cycles durant la phase de développement

Le , par Amine Horseman

24PARTAGES

1  0 
Robert C. Martin alias Uncle Bob revient avec un nouveau billet dans sur son blog « Clean Code », avec pour sujet : le Test Driven Development (TDD).
Cette méthode de développement axée sur l’écriture des tests avant le code obéit à trois lois :
  • première loi : toujours écrire le test avant d’écrire le code de la fonction testée ;
  • deuxième loi : définir dans le test les comportements et les résultats attendus de la fonction testée ;
  • troisième loi : écrire dans la méthode testée le code suffisant afin que le passage du test soit un succès.

Le développeur devrait garder ces trois lois à l’esprit pour chaque ligne de code qu’il écrit. Mais selon les explications de Robert Martin, un codeur TDD respecte durant la phase de développement trois autres cycles :

  1. Le micro-cycle (Red-Green-Refactor) : répété chaque minute, il se base sur l'idée que « nos esprits limités ne sont pas en mesure de poursuivre les deux objectifs simultanés de tous les systèmes de logiciels, dont un comportement correct et une structure correcte. Donc, le cycle RGR met d'abord l'accent sur le travail de faire correctement le logiciel, avant de se concentrer la structure du logiciel ».
    Les règles de ce cycle sont simples :
    • créer une unité de tests ;
    • écrire le code de production qui permet de passer ce test avec succès ;
    • nettoyer le gâchis que vous venez de faire.

  2. Le milli-cycle (Specific/Generic) : répété chaque 10 minutes, se base sur le principe suivant :
    • plus les tests sont spécifiques, plus le code devient générique.
    « On dit souvent que la structure à grain fin des trois lois et le cycle Red-Green-Refactor mènent à des optimisations locales ». Ces optimisations locales font parfois que le développeur se trouve « bloqué » à cause du manque de généralisation. Si cela arrive, « la seule solution est de revenir en arrière à travers les tests précédents, les supprimer, jusqu'à atteindre un test à partir duquel il peut prendre un autre chemin ».
  3. Le cycle primaire : répété chaque heure, son objectif est de faire en sorte que les autres cycles nous conduisent bel et bien vers une architecture claire.
    Ainsi, chaque heure, le développeur doit « s’arrêter pour regarder l'ensemble du système » afin de détecter « les limites architecturales » de son logiciel et voir si sa solution suit une logique bien définie.

Source : Clean Code Blog

Et vous ?

Êtes-vous d’accord avec l’avis de Robert Martin ?

Utilisez-vous (ou utiliserez-vous) le Test Driven Development ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Arnaud13
Membre averti https://www.developpez.com
Le 31/12/2014 à 12:01
Citation Envoyé par Angelsafrania Voir le message
En gros on nous dit, réfléchissez pas trop, coder et après seulement faite du propre en gros c'est ça ?
Je penses que c'est plutôt dans le sens on optimise après. Je ne sais plus où j'ai lu ça, mais je suis complètement d'accord, le code c'est comme une rédaction. Il faut se relire, changer certaines tournures de phrases, alléger le style par endroit, etc... Dans une copie écrite, on ne doit jamais rendre le premier jet. Pour le code c'est pareil.
2  0 
Avatar de Angelsafrania
Membre confirmé https://www.developpez.com
Le 31/12/2014 à 11:32
Je ne comprend pas pourquoi :
plus les tests sont spécifiques, plus le code devient générique.
Qu'est ce qui permet de dire ça ?
Donc dans le milli-cycle, on pète un peu tout ce qu'on à fait, pour amener de la généricité. Et dans le cycle primaire on peut péter pour qu'on ai une archi correcte ?
En gros on nous dit, réfléchissez pas trop, coder et après seulement faite du propre en gros c'est ça ?
[EDIT]
C'est n'est pas une critique juste un constat pour le faite de faire en draft et revoir après.
Je suis comprend l'utilité de développer et d'utilisé les bon design patern qui servent (ca évite de l'anti patern).
[/EDIT]
1  0 
Avatar de Mens Pervincet
Membre habitué https://www.developpez.com
Le 05/01/2015 à 22:29
plus les tests sont spécifiques, plus le code devient générique.
Citation Envoyé par Angelsafrania Voir le message
Je ne comprend pas pourquoi :
Qu'est ce qui permet de dire ça ?
Donc dans le milli-cycle, on pète un peu tout ce qu'on à fait, pour amener de la généricité. Et dans le cycle primaire on peut péter pour qu'on ai une archi correcte ?
En gros on nous dit, réfléchissez pas trop, coder et après seulement faite du propre en gros c'est ça ?
[EDIT]
C'est n'est pas une critique juste un constat pour le faite de faire en draft et revoir après.
Je suis comprend l'utilité de développer et d'utilisé les bon design patern qui servent (ca évite de l'anti patern).
[/EDIT]
Moi je suis plutôt d'accord avec cette assertion, voici mon interprétation:
  • Plus un test est spécifique, moins le bloc de code testé est étendu.
  • Cela veut dire que les blocs testés sont plus petits et plus nombreux.
  • Un bloc testé (et donc testable) est un bloc ayant un contrat clair, une entrée et une sortie bien définies et attendues.
  • Ces blocs peuvent donc être réutilisés dans d'autre contextes.


On peut aussi procéder par analogie: on peut construire des formes plus variées, dans des contextes bien plus variés en utilisant des petites briques qu'avec des gros blocs de marbre.

Je ne suis pas forcément un adepte rigoureux du TDD. Cependant étant donné ce que l'on voit comme code quotidiennenement, force est de constater que les tests unitaires constituent un excellent garde-fous contre les "Fourre-tout design pattern" et codes procéduraux aux effets de bords imprévisibles. Le TDD a le mérite d'orienter naturellement le développeur vers du fonctionnel, de réflechir aux entrées / sorties de ses fonctions, ce qui est à mon avis le B-A BA, pas toujours respecté du développeur.
1  0 
Avatar de copeau31
Membre du Club https://www.developpez.com
Le 09/01/2015 à 1:04
Citation Envoyé par Gulien Voir le message
Y a des gens qui ont le temps de faire du TDD en entreprise ?
Ça me parait utopique tout ça (je peux me tromper).

Perso je ne suis pas fan de cette méthode à la base donc ...
Oui.
Exceptionnellement, c'est arrivé.

Notamment une fois: Je me suis retrouvé à devoir faire un projet d'une centaine de jours. Mais sur ce projet personne n'est venu me demander des comptes, et pour une fois j'ai pu travailler "normalement" (les guillemets sont là parce que travailler normalement est malheureusement très anecdotique). Donc, loin des indicateurs d'avancement, et tant mieux parce que le nombre de lignes de codes écrites est resté à zéro presque jusqu'à la fin du projet
Et voilà, une fois le besoin bien clarifié avec le client (0 lignes de code), le design bien posé (0 lignes de code) les tests autos et sur banc bien écrits pour couvrir le besoin (et bien sûr, tous KO, base du tdd) (ok, là il y a des lignes de codes, mais 0 fonctionnalités implémentées)... Eh bien à ce moment là écrire le code a été pratiquement immédiat ! (et même si je m'attendais à de la facilité, je ne m'attendais pas à ce que ça soit à ce point là)
Résultat, pratiquement 60% de surprod. Je vous laisse faire les comptes.

Et je tiens à préciser que ce n'étais pas un projet spécialement adapté au tdd, juste un comme les autres.
Dernier point: le tdd n'est pas le seul facteur ici, l'autre étant d'avoir pu (et c'est rare aussi) clarifier le besoin suffisamment tôt dans le cycle de vie du projet.
1  0 
Avatar de renoo
Membre éprouvé https://www.developpez.com
Le 03/02/2015 à 21:21
Citation Envoyé par Cyrilange Voir le message
Grosse perte de temps. Je n'ai jamais et je ne ferais jamais ce genre de chose.
Tout le contraire pour moi. Gros gain de temps, je code les tests d'abord puis la fonctionnalité buggée à l'arrache pour que ca compile et que ca casse. Ensuite je code la fonction jusqu'à ce que le(s) test(s) passent. Je gagne du temps à trouver les bugs (du temps perdu avec le debuger pour des bugs à la con) et je pense avoir un code moins buggé avec ça (les bugs chez les clients c'est toujours le pire : cout en terme d'image, difficulté à reproduire, se faire expliquer...). Ca permet aussi de donner un bon rythme (test, dev, refactor). En bonus, j'ai un code testé que je peux faire évoluer sans trop casser.
1  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 04/02/2015 à 12:25
Citation Envoyé par renoo Voir le message
je code les tests d'abord puis la fonctionnalité buggée à l'arrache pour que ca compile et que ca casse.
Malheureux, c'est du pain bénit pour les détracteurs de TDD qui vont dire que tu perds du temps à imaginer ton implémentation à l'arrache pour ensuite l'effacer

Plus sérieusement, je préfère créer juste une méthode vide ou qui throw une NotImplementedException (souvent générée automatiquement par une fonctionnalité de refactoring dans l'IDE), ça suffit pour faire planter le test.
1  0 
Avatar de renoo
Membre éprouvé https://www.developpez.com
Le 04/02/2015 à 21:08
Citation Envoyé par Luckyluke34 Voir le message
Plus sérieusement, je préfère créer juste une méthode vide ou qui throw une NotImplementedException (souvent générée automatiquement par une fonctionnalité de refactoring dans l'IDE), ça suffit pour faire planter le test.
Oui c'est bien mieux comme ça et c'est plus ça que je fais d'ailleurs : une fonction qui a le bon profile mais la plus courte possible et buggée (return 1; si ca retourne un int) et c'est vraiment le plus rapide à coder. Le truc c'est que cette étape permet aussi tester un peu le test.

Mais sinon écrire une première implémentation pas top sur certains aspects (pex perf & co) et y revenir ensuite avec un ensemble de tests dont une partie peut être conservée... ça me semble plutôt du temps gagné, d'autant plus que peut être il n'y aura pas à revenir dessus (premature optimization is the root of all evil).
1  0 
Avatar de boero-teyssier Greg
Nouveau membre du Club https://www.developpez.com
Le 31/12/2014 à 15:51
Citation Envoyé par Arnaud13 Voir le message
Je penses que c'est plutôt dans le sens on optimise après. Je ne sais plus où j'ai lu ça, mais je suis complètement d'accord, le code c'est comme une rédaction. Il faut se relire, changer certaines tournures de phrases, alléger le style par endroit, etc... Dans une copie écrite, on ne doit jamais rendre le premier jet. Pour le code c'est pareil.

Pour moi l’atout majeur de la TDD et de ne pas à avoir à revenir sur ton code pour effectuer des changements majeurs donc tu dois le panser avant de l’écrire.
Pour reprendre ta métaphore, quand tu fais une rédaction tu écris un plan avant de te lancer dans sa rédaction ? là ton plan ce sont tes tests.

En lisant l’article original, quand il dit de détruire les tests précédant cela ne veut pas dire tous les tests.
Si tu es bloquée dans l’écriture des tests dans cette phase c’est que tu as un problème d’architecture donc pour corriger cela tu dois faire du refactoring ,
en TDD on dit que l’architecture émerge.
0  0 
Avatar de Arnaud13
Membre averti https://www.developpez.com
Le 31/12/2014 à 16:05
Citation Envoyé par boero-teyssier Greg Voir le message
Pour moi l’atout majeur de la TDD et de ne pas à avoir à revenir sur ton code pour effectuer des changements majeurs donc tu dois le panser avant de l’écrire.
On est bien d'accord. Je parles d'optimisations, pas de changement du fonctionnement des méthodes.
Je penses qu'on veut dire la même chose, quand tu parles de "refactoring".
0  0 
Avatar de Gulien
Membre habitué https://www.developpez.com
Le 31/12/2014 à 16:09
Y a des gens qui ont le temps de faire du TDD en entreprise ?
Ça me parait utopique tout ça (je peux me tromper).

Perso je ne suis pas fan de cette méthode à la base donc ...
0  0