Publié par

Il y a 9 ans -

Temps de lecture 13 minutes

L’avocat du TDD

Ceci est une fiction. Toute ressemblance avec des personnes existant ou ayant existé serait totalement fortuite.

Palais de justice de Paris, lundi 21 mars.

Une fois n’est pas coutume, des développeurs sont assis sur le banc des accusés! Ils sont inculpés de faire perdre des millions d’euros à nos chères compagnies du CAC40 en écrivant du code voué à crouler sous son propre poids.

Mr Tedd, praticien du Test Driven Development, est aujourd’hui jugé ainsi que quelques uns de ses collègues : Mr Whatever, Mr Guru, Mrs Clickaway et Mr Testafter.

Prévoyant et confiant, il sera défendu par son avocat : Maître Darrow. Ils ont convenu ensemble de la stratégie à adopter: il faudra pointer du doigt les mauvaises habitudes souvent utilisées et mettre en avant les bonnes pratiques qu’il a appliqué tout au long des projets qui lui ont été confiés.

L’audience est ouverte

Le Président, Mr Beck, ouvre la séance en rappelant les chefs d’accusations aux jurés:

  • Le code applicatif contient trop de bugs
  • Le code applicatif n’est pas testé
  • Le code applicatif est pour la plupart du temps incompréhensible et reste trop volumineux pour le nombre de fonctionnalités
  • La modification et l’amélioration du code applicatif existant est trop risqué à entreprendre

La parole est à la défense. Maître Darrow, soucieux de capter l’attention de son audience, rappelle le contexte:

Nous sommes en 2011. Dans les missions dans lesquelles mon client, Mr Tedd, intervient, écrire du code représente 80% de son temps. Ce code capture des règles métiers plus ou moins complexes et qui évoluent dans le temps. Visuellement son travail se traduit souvent par ce qu’on appelle un front end sur lequel un utilisateur tel que vous et moi pouvons interagir. Un bon exemple serait un site de réservation de billets de train au niveau Européen. Vous voyez donc, Messieurs et Mesdames les jurés que l’enjeu est de taille, l’erreur coûte chère et qu’elle n’est donc pas acceptable.

Aujourd’hui, je vais vous démontrer que mon client, Mr Tedd, adopte les pratiques adéquates pour rendre son code fiable, évolutif et pérenne.

Laissez-moi d’abord vous présenter quelques types classiques de développeurs. Si je n’enlève rien aux connaissances techniques et aux talents d’ingénieurs de ces personnes, je leur reprocherais cependant une attitude trop laxiste quant à la fiabilité et la pérennité du code qu’ils soumettent mais aussi une négligence au regard des méthodes qui permettraient d’améliorer considérablement la qualité globale des projets auxquels ils participent.

Permettez-moi de commencer par le cas de Mr Whatever.

Mr Whatever

Tous les regards se tournent vers ce grand gaillard assis au bout du banc des accusés.

Mr Whatever, si vous me permettez de vous citer, vous m’avez dit :

« Moi je fais juste confiance à mon code. Il compile c’est donc qu’il fonctionne. »

Je pense que Mr Whatever n’est jamais resté assez longtemps dans les entreprises pour lesquelles il travaillait pour savoir que son code en production posait plus de problèmes qu’il n’en résolvait. Je rappelle pour les profanes dans l’assistance, que la production est la plateforme exposée au grand public donc aux vrais utilisateurs. C’est dans cet environnement que la charge sur le système se révèle soutenue et que, potentiellement, tous les chemins possibles dans le code écrit sont réalisés en concurrence !

Le problème de Mr Whatever est qu’il ne sait réellement si son code fonctionne que lors de la phase de tests intensifs. Pour lui, tester c’est la tâche de ce que l’on appelle l’équipe de QA, tiré de l’anglais Quality Assurance, et qui s’assure de la qualité du logiciel fournit. Si son code ne fonctionne pas, ils le lui indiqueront et il corrigera. On voit bien que sa responsabilité de fournir du code qui fonctionne lui échappe.

L’avocat se tourne vers l’audience et continue :

Nous ne nous attarderons pas plus sur le cas de Mr Whatever, il appartient à une génération un peu dépassée par les événements.

Cette dernière phrase entraine de légers gloussements dans l’assistance.

Mr Guru

Maître Darrow, après avoir jeté un rapide coup d’œil aux papiers étalés sur son bureau, se tourne vers la personne assise aux côtés de Mr Whatever.

Passons au cas de Mr Guru. Cas intéressant puisqu’il représente l’archétype de l’informaticien auquel on accorde toute sa confiance !

Ses connaissances et son expérience en font un expert dans l’écriture du code. Cependant, il ne teste jamais ce qu’il écrit. Il n’introspecte pas. Perte de temps pour lui ! Il a écrit assez de plateformes pour savoir comment écrire la vôtre. Très bien. Nous aurons alors un code de qualité. Cette affirmation est correcte si votre équipe n’est formée que de Mr Guru ! Situation atypique s’il en est, et bon courage pour les batailles d’ego. Mais bon … passons.

L’avocat lève le bras pointant l’index vers le plafond et lance :

Si notre postulat de départ est que les entreprises ne travaillent qu’avec des profils tels que celui de Mr Guru, voici les problèmes que cela entrainerait :

Maître Darrow marque un silence pour permettre aux jurés de bien se concentrer sur ce qui va suivre.

Le premier problème serait une pénurie rapide de Mr Guru sur le marché. Toutes les entreprises ne pourraient pas en recruter et seraient dans l’incapacité de produire des applications de qualité. Un peu fantasque je vous l’accorde, mais totalement valide avec le postulat de départ.

Le deuxième problème impacterait le budget de l’entreprise. Un Mr Guru cela coûte cher ! Combien seriez-vous prêt à dépenser pour une armée de Mr Guru ?

Le dernier souci, et non des moindres, serait de s’assurer qu’on ne recrute que des Mr Guru. S’il y a un responsable des ressources humaines dans la salle, il m’accordera que la tâche se révélera ardue. Par ailleurs, je note aussi qu’il arrive à Mr Guru d’être fatigué ou d’être ennuyé, Guru ou pas, il reste humain. De ce fait, il est toujours possible qu’un expert introduise des erreurs dans votre code de production sans le vouloir.

De plus une question se pose. Faut-il bannir les développeurs juniors de votre équipe de développement ? Avons-nous peur qu’ils insèrent des erreurs dans le code ? Un bon manager vous dira que cela serait une faute. Une équipe doit être hétérogène en caractère. Pourquoi se couper du dynamisme des développeurs juniors, de la facilité avec laquelle ils manient les dernières technologies et de leur passion encore verte pour la programmation ?

Après une longue pause, l’avocat fixe chaque membre du jury tour à tour, et conclut :

Nous voyons bien qu’en réalité une équipe est constituée de profils différents et hétérogènes en compétence. Il nous faut donc une pratique commune de développement qui nous assure que Mr Guru et son collègue, plus junior, écrivent leur code d’une manière uniforme et testée sans porter atteinte à leur créativité.

Dans la salle, quelques personnes opinèrent du chef. Sûrement des développeurs!

Mrs Clickaway

L’avocat se rapproche de quelques pas du jury tout en désignant de la main la jeune femme assise au milieu du banc des accusés.

Maintenant le cas touchant de Mrs Clickaway. Mrs Clickaway est bien intentionnée. Elle veut savoir si son code fonctionne. Pour cela elle adopte un cycle rapide d’écriture de code, et de déploiement de son application dans son environnement local. Pour tester, elle clique et re-clique jusqu’à ce qui lui semble avoir parcouru tous les recoins des fonctionnalités qu’elle a implémentées. Pourtant, Mrs Clickaway utilise très mal son temps de développement. Pour les plus techniciens d’entre vous, je dirais qu’elle oscille entre stacktrace, long démarrage de serveur et debuging en tous genres !

En effet, alors qu’elle aurait l’opportunité d’écrire son code tout en l’introspectant, grâce aux trés bonnes librairies logicielles mises à disposition aujourd’hui, elle choisit de tester en mode boite noire. Pour les profanes dans la salle, le mode boîte noire est une série de tests qui se fait à un haut niveau de l’application sans se préoccuper réellement de la structure et du fonctionnement interne.

Je reproche donc à Mrs Clickaway de ne pas se concentrer sur son coeur de métier qui est la production d’un code propre et fiable. Pour être franc, je pense que Mrs Clickaway n’est jamais sûre de ce qu’elle écrit et qu’elle veut se donner bonne conscience avant de livrer son code à l’exploitation.

Je vous le dis, ne pas choisir l’introspection, c’est ne pas choisir de réfléchir sur ce que l’on produit et c’est ne pas choisir l’amélioration de son propre code. Mesdames et Messieurs les jurés, vous m’accorderez que c’est un peu surprenant et relève d’un comportement irresponsable pour un développeur.

Sur le banc des accusés Mrs Clickaway semble anéantie et confuse par cette série d’accusations.

Mr Testafter

Passons maintenant à mon cas favori. Mr Testafter.

Mr Testafter est sur la voie de la rédemption, seulement il a pris à gauche alors qu’il fallait prendre à droite ! Que je vous explique. Mr Testafter a bien compris qu’il fallait tester son code. Cependant, il écrit les tests après avoir écrit ce fameux code de production. Normal vous me direz. Eh bien non ! Cela pose plusieurs problèmes:

Comme tous les développeurs, Mr Testafter passe beaucoup de temps à écrire son code. Quand il en a enfin fini, c’est un soupir de soulagement avec une pause café bien méritée. Enfin jusqu’à ce qu’il réalise qu’il n’a écrit aucun test ! Pour ne rien arranger, il a déjà indiqué fièrement à son manager que son travail était fini. Qu’à cela ne tienne, il va ajouter rapidement les tests, parce qu’après tout, il n’a pas que ça à faire.

C’est à ce moment qu’il doit faire un effort non négligeable: se remémorer les spécifications, imaginer des cas d’utilisations pour finalement… relire son code afin de savoir quoi tester !

L’avocat lance un regard vers Mr Testafter sur le banc des accusés. Ce dernier fixe le plafond.

Idéalement, s’il veut que ses tests soient utiles, c’est-à-dire compréhensibles par un autre développeur, clairs, découpés en spécifications et couvrant toutes les fonctionnalités, il doit reprendre sa réflexion à zéro.

Cependant, Mr Testafter à ce moment précis est pressé. Il n’adoptera pas une démarche d’écriture « fonctionnalité par fonctionnalité ». Plus grave, il ne pensera pas aux effets de bord, car puisque son code est déjà écrit, il est censé fonctionner ! Summum du contre-sens, pour les praticiens du TDD dans la salle, Mr Testafter ne passe pas par la phase d’un test qui échoue. En réalité, Mr Testafter ne voit aucun test échouer ! Bizarre pour quelqu’un qui veut savoir si son code fonctionne.

Une fois les tests ajoutés, laissez-moi vous décrire le résultat, cela se vérifie presque à chaque fois. Il y a toujours plus de code généré qu’il n’en faut et le code contient de la duplication. Mr Testafter n’est pas dans une optique de code minimal pourtant si importante dans les énormes bases de code d’aujourd’hui. Les tests sont désordonnés, ne sont pas organisés en terme de fonctionnalités et contiennent eux aussi de la duplication.

Invariablement aussi, une fois les tests ajoutés, le code restera tel qu’il a été écrit à l’origine. Pas d’optimisation, de minimalisation ou de recherche d’expressivité du code. Le plus grave cependant est d’obtenir ce que l’on appelle un effet gruyère sur la classe testée: des bouts de code resteront non testés. Pour ceux qui me suivraient encore dans l’assistance, je ne vous conseille pas de refactorer du gruyère !

Sur cette dernière phrase, l’audience se partage entre face crédules et sourires.

Mr Tedd – Vers un code agile

Il est l’heure maintenant pour Mr Darrow de défendre son client. Il tient à expliquer aux jurées les principes fondamentaux sur lesquelles repose la méthode que son client Mr Tedd utilise. Il enchaine alors :

A travers les différents profils que je vous ai présenté, nous avons pu voir les insuffisances de certaines techniques de développement.

Laissez-moi donc maintenant vous résumer la manière d’écrire du code applicatif la plus à même à répondre à la problématique de tolérance au changement du monde du logiciel. C’est celle que pratique mon client. C’est le Test Driven Development. Cette méthodologie se résume avec la phrase suivante :

Tout code de production a été écrit pour faire passer un test qui au départ échouait.

Ce postulat pour certains peut sembler abstrait, cependant il se met en pratique tous les jours avec succès. Laissez-moi maintenant énumérer les corollaires directs de ce postulat.

Dans la salle on aurait pu entendre une mouche voler. L’avocat commence à énoncer :

Tout code de production est donc testé. Il n’y a pas plus de code que de fonctionnalités voulues et votre base de code est donc minimale. Toute fonctionnalité étant couverte par un test, vous savez instantanément lorsqu’un test échoue qu’une fonctionnalité n’est plus respectée et vous pouvez prendre aussitôt les mesures appropriées.

Ce code, proprement testé, vous pouvez le simplifier, l’améliorer et le nettoyer sans risque. C’est ce que l’on appelle le refactoring. Votre code devient par conséquent malléable, flexible et donc agile. C’est le moyen d’éviter que votre code ne s’effondre sous son propre poids !

L’avocat continue :

Mesdames et Messieurs les jurés, je vous le demande : Pour ceux qui connaissent le monde du logiciel, quel est le mot le plus important dans l’agilité?

Au vu des visages dubitatifs du public, et de cette femme âgée assise au premier rang qui avait commencé à tricoter, Maître Darrow comprit qu’il aurait à apporter lui-même la réponse.

Le Feedback ! Voilà le concept le plus important à mettre en place. Le Test Driven Development vous permet de mettre en place la plus petite boucle de feedback du monde agile. Instantanément vous savez si votre code répond à vos exigences.

Alors que Mr Darrow est au beau milieu de la défense de son client, le président Mr Beck, avec un geste d’impatience de la main, déclare :

Merci Mr Darrow. Cependant, avant que vous poursuiviez, l’avocat de la partie civile souhaite interroger maintenant votre client Mr Tedd. Et exceptionnellement, je ly’autorise.

Mr Darrow ne peut qu’abdiquer et Mr Tedd se dirige alors vers la barre pour être interrogé. C’est alors qu’un petit homme au front suintant, très agité, s’avance au centre. C’est Mr Pascal, l’avocat de la partie civile. Le contre interrogatoire peut commencer.

La suite du procès dans un prochain article.

Publié par

Publié par Simon Caplette

Simon a rejoint Xebia en 2010 après cinq années passées à Londres où il a travaillé sur diverses plate-formes Spring et J2EE. Depuis trois ans, il applique avec succés les methodes XP et plus particulièrement TDD.

Commentaire

20 réponses pour " L’avocat du TDD "

  1. Publié par , Il y a 9 ans

    J’espère que ce sera pas un avocat commis d’office M. Pascal, car il a matière à développer… Mais je le sens mal avec son « front suintant » et « très agité ».

  2. Publié par , Il y a 9 ans

    Ton article est intéressant. Il met en évidence les bénéfices du TDD en exploitant les faiblesses des approches fréquemment utilisées.

  3. Publié par , Il y a 9 ans

    Article très drôle, prouvant à quel point ne pas pratiquer le TDD est anti-professionnel. Ceci dit, le feedback le plus court du développeur agile n’est pas son test, mais sa paire.

  4. Publié par , Il y a 9 ans

    Trés bon point Jean-Baptiste. Et maintenant, imaginons une paire pratiquant le TDD !

  5. Publié par , Il y a 9 ans

    Je trouve que la partie sur Mr. Testafter est mal expliqué et démontre le biais de l’auteur pour le TDD.

    Le premier problème présenté : que Mr. Testafter se vante d’avoir completé son travail avant d’écrire des tests. Eh bien, ça ne montre pas de problème dans l’ordre qu’il travaille (code-test ou test-code), mais plutôt qu’il a le tort de croire qu’il a fini alors qu’il n’y a pas de test.

    Le deuxième : il doit « se remémorer les spécifications, imaginer des cas d’utilisations pour finalement… relire son code afin de savoir quoi tester ! » Ceci n’est pas non plus un problème de l’ordre dans lequel il fait son travail : on pourrait très bien dire de Mr. Tedd qu’après avoir passé un bon bout de temps à écrire ses tests, il doit maintenant se remémorer les spécifications, imaginer comment implémenter telle ou telle fonctionnalité, pour finalement…relire ses tests afin de savoir quoi coder ! Le vrai problème ici est qu’il a pris un morceau trop grand, et donc, une fois qu’il arrive à la fin d’une partie (que ce soit code ou test), il a déjà oublié comment il l’avait commencé.

    Ensuite : qu’est-ce qui empêche Mr. Tedd de faire des tests incompréhensibles, pas clairs, et pas bien découpés, avant de commencer à coder ?

    Ensuite : pourquoi est-ce qu’un test qui passe, serait bizarre ? Si j’ai sous la main du code que Mr. Tedd a écrit il y a un an, et je lance les tests pour « savoir si son code fonctionne », dois-je trouver bizarre que les tests passent ? En gros, cette petite raillerie enfantile n’a aucun sens et n’ajoute rien pour souligner quel avantage Mr. Tedd aurait sur Mr. Testafter.

    Au final : Pourquoi l’ordre code-test empêcherait la refactorisation du code ? Et, pourquoi l’ordre test-code empêcherait l’existence d’algorithmes mal pensés qui ont besoin d’être refactorisés ? Encore une fois, l’auteur lance des accusations à Mr. Testafter qui s’appliquent très bien aussi à Mr. Tedd.

    Je devrais peut-être mentionner que je ne suis pas contre le TDD. Au contraire, je trouve que c’est plutôt bien. Mais soyons honnêtes. Testez vos raisons contre toutes les entrées possibles avant de déclarer que vos arguments tiennent. ;)

  6. Publié par , Il y a 9 ans

    @Cid

    1. Pour le premier et deuxième problème que tu reprends l’idée est de souligner que Mr Testafter perd beaucoup de temps finalement pour essayer d’arriver aux résultats qui sont offert par le test first. Pour résumé, ses intentions sont bonnes mais sa démarche est moins productive.
    2. De la même façon, il n’est pas impossible à Mr Testafter de faire des tests clairs et concis. Cependant, il y a une méthode qui s’y prêtre mieux, et qui intrinsèquement propose une approche par fonctionnalité.
    3. Un test qui passe n’est pas bizarre, mais un test qui n’a jamais été dans le rouge est un test qui n’a pas été validé.
    4. L’ordre code-test n’empêche pas la refactorisation, cependant il la rend beaucoup plus difficile, risqué et moins naturelle. En effet, en TDD, la refactorisation se fait graduellement et est donc plus facile à aborder. En test after, le développeur doit refactoriser toute son implémentation à la fin.

    En règle général, basé sur l’expérience, je dirais que le test after, règle mal le problème de la duplication et ne permet pas d’obtenir un code minimal.

  7. Publié par , Il y a 9 ans

    Héhé super. J’attend la suite…

  8. Publié par , Il y a 9 ans

    Il faudrait demander à M. Specif de défendre un peu M. Tedd…

    Ce que voudrait bien M. Specif, c’est que M. Tedd prenne son cahier des charges en main. Il le lit pour de vrai, même rapidement. Il traduit les services demandés en interface et (hop) il écrit des tests (vides au départ) avec tous les cas proposés dans le cahier, de manière exhaustive. Chacun des tests met en évidence les paramètres d’entrée et les résultats attendus. Et puis il y a aussi un peu de doc (javadoc ?). A ce stade, tous les tests sont rouges puisque l’implémentation des services n’a même pas commencée. Mais en tous cas, M. Specif est content car il y a au moins une personne qui s’est intéressée à son travail d’expert fonctionnel et qui travaille en équipe avec lui.

  9. Publié par , Il y a 9 ans

    @Thierryler
    J’aime bien ce Mr Specif. Il est vrai qu’une démarche test first remet au centre l’aspect contrat des spécifications et la collaboration avec le métier. Je me suis souvent retrouvé dans la situation où essayant de formuler mon prochain test, j’ai dû faire appel aux équipes métiers pour précisions ou ajustements. Cela m’a forcé à clarifier avant d’écrire le code. Et on sait bien qu’une fois que le code est écrit, il est plus difficile de l’enlever ;)

  10. Publié par , Il y a 9 ans

    On y arrive, mais je ne suis toujours pas convaincu. :)

    1. Pourquoi est-ce que l’écriture des tests après avoir codé doit prendre plus de temps que l’écriture des tests avant de coder ?
    2. Je suis plutôt d’accord, et je pense que ce point souligne le vrai avantage du TDD : c’est une sorte de jeu psychologique. Faire de bons tests après avoir codé demande une attention à rester fidèle aux specs/à l’API et non pas à faire des hypothèses biaisées sur la connaissance du code déjà écrit. Ce n’est pas impossible, mais ça introduit des risques dans le « wetware ».
    3. Un test qui est en rouge simplement parce qu’il n’y a pas de code ne me semble pas être une validation très significative.
    4. A mon avis, si Mr Testafter a écrit tellement de code sans ajouter de test qu’il risque de se tromper en refactorisant, c’est qu’il a pris un trop gros morceau – il est allé trop loin sans faire ses tests (le 2ième problème que j’ai signalé plus haut). Je pense que la règle à retenir ici n’est pas « tester avant de coder » mais plutot « avoir des tests avant de refactoriser ».

  11. Publié par , Il y a 9 ans

    Tu gagnes du temps à écrire tes tests avant car c’est le bon moment pour te poser les bonnes questions… Si tu pars d’un cahier des charges, comme le souhaite surement ton chef de projet, tu as déjà toutes les infos. Tu fais des tests vides et/ou rouges. Là tu es à peu près certain de prendre en compte tous les cas intéressants. Quand ensuite tu écris ton code applicatif, tes tests deviennent progressivement verts. Quand tout est vert, c’est fini. Quand tout est vert, plus besoin de se poser de question.

    En fait, quand tu écris d’abord tes tests, l’expérience montre que tu te poses les vraies bonnes questions et que ton code sera lisible. Il sera d’ailleurs d’autant plus lisible que tes tests correspondent à des specs. Du coup, tes tests sont de la doc…

    Quand au contraire tu écris tes tests après, l’expérience montre que c’est longtemps après, que ça va être baclé (c’est humain) et que tu vas te prendre la tête à trouver les tests qui vont bien. Alors qu’on s’en fou des tests qui vont bien. On veut juste que ça répondre à un contrat de service…

  12. Publié par , Il y a 9 ans

    1. Pourquoi est-ce que l’écriture des tests après avoir codé doit prendre plus de temps que l’écriture des tests avant de coder ?
    En TDD, on ne s’intéresse qu’à une seule fonctionnalité à la fois, ce qui rend le test à faire plus facile à cerner.
    Effectuer les tests après demande une réflexion pour être exhaustif.

    3. Un test qui est en rouge simplement parce qu’il n’y a pas de code ne me semble pas être une validation très significative.
    En comparaison de tests après dév, si !
    Le principe du TDD repose sur une réalisation minimum pour faire qu’un test échouant devient passant. De ce fait, si le test passe, c’est grâce au développement qu’on vient d’effectuer.
    Au contraire, en faisant le test après développement, on ne sait pas si le test passe par « coincidence » ou s’il passe parcque le dév réponds aux spécs.

    Exemple simple : je dois réaliser une méthode chargée de parser une String pour la transformer en Integer avec les 4 règles suivantes :
    1. Si je passe null j’attends 0;
    2. Si je passe chaîne vide («  »), j’attends 0 également;
    3. si je passe une chaîne non parsable, j’attends une exception
    4. Sinon, j’attends l’entier correspondant.

    En mode « Monsieur/madame Testafter » :
    Grossièrement, le test correspondant à la règle 1 serait assertEquals(0, maMethode(null))
    => le test est passant, cool

    Le test 2 ressemblant au 1, je fais un copier / coller qui tourne mal et à la place de assertEquals(0, maMethode(«  »)), je reste avec assertEquals(0, maMethode(null))
    => le test est passant par « coïncidence », c’est à dire, non pas grâce au dév que je viens d’effectuer, mais parce que j’ai mal écris mon test ! (j’ai fais une erreur qui annule peut être une autre erreur dans mon dév et rien ne me permet de la détecter).

    En mode « Monsieur/madame TDD », ce type d’erreur est facilement détectable :
    J’écris le test correspondant à la règle 1 et je m’assure qu’il ne passe pas; ensuite, j’effectue uniquement le dév qui fera que ce test passe
    => le test est passant, je passe au test 2

    Je refais le copier / coller qui tourne mal et « tiens, mon test passe alors que je n’ai encore rien écris ! »
    Mon erreur d’inattention détectée, je peux « corriger » mon test et continuer sur ma lancée : le test ne passe pas; je réalise; le test passe; au suivant !

    Le TDD a donc le gros avantage de permettre de « tester » les tests, ce qui est moins facilement faisable en mode « Testafter » (introduire volontairement des erreurs dans le code pour s’assurer que le test associé échoue par exemple)

  13. Publié par , Il y a 9 ans

    Tu peux aussi parler de M. Céfédéprozé. Lui, ce qu’il aime, c’est le chiffre qui diminuent, notamment ceux fournits par M. Réstafère. Et ce qu’il n’aime pas, mais alors vraiment pas, c’est quand M. Réstafère lui annonce qu’il faut des jours en plus car les développeurs n’avaient pas pris en compte un cas important, qui était pourtant indiqué par M. Spécifeux (le nouveau nom de M. Spécif pour échapper aux clients mécontents de Aibex, le méchant concurent de Xebia lol)

  14. Publié par , Il y a 9 ans

    Dans le cadre d’une application n-tiers (Flex/Spring), et j’avais la responsabilité d’écrire des services métier très lourdes en règles de gestions.

    Comme j’étais un développeur du genre de Mme/Mr TestAfter j’écrivais le code et les tests, bah, sont toujours, resté en bas de la liste des priorité. je croyais que pour être productif je devais écrire le max de code. jusqu’au jour qu’on m’a condamné de rester des heures tardives et de bosser des week-end et des week-end derrière les barreaux de mon poste ( tout seul, privé du plus cher que j’ai; ma liberté :( ), et d’apprendre à changer mes habitudes en adoptant le TDD.

    Ma méthode de travail était de coder les services et de m’assurer qu’il marchait en l’attaquant avec la couche présentation, après chaque ligne ajouté je devais redémarrer mon Jetty, lancer mon swf, s’authentifier, chercher l’ihm qui appelle le service, en suite la charger avec données, après aller faire des points d’arrêt, débugger débugger, des F6 et des F5 de tous les genre ou si non, tracer tracer. bref du stress et je l’avoue j’étais pas du tout productif au contraire de se que je croyais, j’étais un quelqu’un de mauvais.

    Et un jour on vient pour me dire, Mr on fait confiance aux services que vous nous développiez, ils marche en prod et tout … Nous avons décidé maintenant d’en vendre un, comme un web service, à notre client FooTelecom, et comme ce client est exigeant, rien ne lui échappe, rapidement, après quelques jours, il revient furieux nous dire que notre service ne marche pas, et nous explique que nous avons oublier de gérer quelques cas de gestion, y compris le null en input que j’ai totalement oublié car mon ihm avec ses validateurs me faisait croire que c’était un détail et s’était inutile de le gérer.

    oh combien je regrette ces jours jours perdu derrière les barreaux.

    Maintenant avec mon nouveau paradigme de dév le TDD expliqué dans l’article, je suis 10 fois plus productif, chaque dév que je fais est de qualité (bah oui même après ma sortie des barreaux, ils m’ont suivi avec un Sonar pour me surveiller tout le temps).

    Impossible de retourner aux ancienne habitudes. je suis maintenant un bon citoyen ,, euhh un un bon développeur :)

  15. Publié par , Il y a 9 ans

    @selkhlifi
    Merci pour partager cette expérience personnelle. C’est bon de lire un peu de concret après cette fiction ;)

  16. Publié par , Il y a 9 ans

    Article intéressant, mais dommage que l’auteur soit aussi partial en faveur du TDD. Je veux bien que l’avocat soit partial, mais le narrateur ne devrait pas l’être.

    Par ailleurs, tout n’est pas blanc ou noir. Le test after a aussi des avantages, et le test before a aussi des défauts, j’espère que la suite du procès le montrera, sinon ce ne sera pas équitable.

    J’ajouterai qu’à mon sens le plus gros problème par rapport aux tests, c’est le manque de littérature sur la question. On trouve des tonnes d’outils, Junit, Easymock, Selenium pour ne citer qu’eux, et des tas de tutoriels de type « les tests unitaires pour les nuls » qui expliquent comment batir votre premier test unitaire pour vérifier que la classe d’exemple simplissime arrive bien à faire des additions, et avec ces connaissances en poche, le développeur arrive à son bureau et là on lui demande

    1) de faire une classe qui va attribuer aux utilisateurs qui se connectent à l’application les privilèges qui leurs sont afférés, compte tenu des groupes auxquels ils appartiennent dans le LDAP et des mappings disponibles dans la base de données

    2) ou encore d’ajouter une nouvelle vue à l’application, qui ne s’affichera que si l’utilisateur a les droits pour, et qui permettra de faire des opérations de CRUD sur la base de données sous réserves que certains tests métiers passent (tests pris en charges par le framework et paramètrés par le biais d’annotations), avec un mécanisme particulier de réservation des ressources.

    Eh bien le développeur lambda, au début il essaye d’extrapoler à partir de son exemple sur le test unitaire des calculatrices. S’il est un peu persévérant, il va essayer de faire des mocks, et puis il va s’appercevoir qu’il ne sait pas comment simuler le comportement du framework, et assez rapidement il va finir par laisser tomber parce qu’il n’a pas toute la semaine pour comprendre comment on fait des tests unitaires dans la vie réelle.

  17. Publié par , Il y a 9 ans

    J’avais essayé de commencer un début de tuto/article sur developpez.com à propos de tous les types de tests, les NR, les unitaires, l’intégration, les perf, charge, ihm, avec des moch comme Mockito, des simulacres comme EasyMoch, du selenium, du reporting et j’en passe. Mais c’est hyper long d’écrire un article qui tient la route… Au final, c’est resté un simple projet : http://thierry-leriche-dessirier.developpez.com/tutoriels/java/dev-et-tests/

    D’ailleurs, il y a une série d’articles sur java-freelance.fr, de Mathilde et JB, que je vous conseille.

    J’avais, pour ma part, commencé un article d’intro à EasyMoch mais pas le temps de le compléter : http://thierry.leriche-dessirier.com/article/intro-easymock.htm

    Pour ma part, je ne vois pas en quoi les TDD peuvent être mauvais, sauf peut-être à donner trop confiance…

  18. Publié par , Il y a 9 ans

    @Lambda
    Je suis d’accord sur le fait que la littérature aborde plus souvent l’aspect apprentissage et pédagogique du TDD et donc s’en tient à des exemples simples. Dans une mission récente, j’ai implementé (en TDD) une connection LDAP en utilisant Spring. Cela a bien fonctionné. J’ai pensé en faire un article pour enfin aborder quelque chose de plus complexe qu’un simple calculateur.

    Sinon une bonne façon d’aborder des problèmes plus complexes en TDD (quand on en a pas l’occasion dans son travail) c’est de participer à des codes retreats, randoris ou autres dojos.

  19. Publié par , Il y a 9 ans

    Intéressant…

    J’y penserai ;).

  20. Publié par , Il y a 7 ans

    Merci pour cet article… Le procès est-il terminé ou bien sommes encore tombés dans des procédures interminables ?
    En espérant avoir la suite.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.