TDR, ATDD sortiront de l'ornière "démo" qu'avec des langages compatibles refactoring
La limite que l'on touche très vite quand on se lance dans des spectests tabulaires en wikitexte fitnesse ou greenpepper, ou même des spectests textuelles BDD JBehave, c'est le temps de mise au point puis de réparation des identificateurs communs entre code de liaison et spectests.
Ces spectests contiennent en effet des centaines de cellules entêtes (ou de mots de phrases, pour BDD) qui correspondent 1 pour 1 à des attributs/paramètres, méthodes, classes java de fixtures (fr. code de liaison). Dans la pratique, le développeur perd bcp trop de temps à établir et réparer cette correspondance : même et surtout en approche "test en premier", la stabilité du test n'est jamais immédiate, les identificateurs - qui correspondent aux concepts manipulés - changent, bougent, se transforment; côté code, le remaniement est aussi fréquemment de mise, pour améliorer la lisibilité du code ou la simplicité du design (on espère pour votre dette technique).
Un outil comme Eclipse apporte la vérification permanente du respect global des identificateurs (merci visual age) et la facilité de remaniement à 1 seul point pour tous (merci intellij) entre "java et java" pourrait on dire ; le développeur est habitué; il aimerait légitimement avoir la même chose entre specstests et codes de liaison.
Faire 2 couches bien distinctes ? le "métier" tel que vu par les tests fitnesse (et = identificateurs/signatures des fixtures), et le métier vu par l'appli, 2 "langages", et compensation totale et complète au niveau de l'implementation des fixtures ? C'est faire l'hypothèse trop souvent fausse que les concepts manipulés en spectests sont rapidement stables (sans parler de changement, juste en parlant de maturité de la compréhension du besoin par ex), et c'est "payer" une compensation par un double modèle et beaucoup de lignes de codes sans forte valeur ajoutée, donc coûteuses et risquées à maintenir. Encore une fois, ça ne se voit pas en démo sans pression sur les délais, et ça se voit très vite en condition réelle, contrainte délai, et en concurrence avec toutes les autres choses qu'on a besoin de faire en projet...
si on réfléchit bien, fixture et feuilles stipulent les mêmes identificateurs; ils ne doivent pas correspondre, ce sont les mêmes; pourquoi avoir 2 langages différents ?
Je crois de plus en plus à la nécessité que les langages d'expression de test soient munis de plugins Eclipse compatibles refactoring a minima. Condition requise pour sortir de l'ornière "démo".
Une prédiction ? Je pense que c'est cuit pour un plugin wikitext-fitnesse pour Eclipse : il n'y a pas de culture "langage/arbre syntaxique" dans la sphère fitnesse... Il y en a en revanche dans la sphère des Langages Dynamiques sur xVM; Je crois donc aux filières type Groovy/EasyB pour le cas Java par exemple (je n'ai pas dit que EasyB était parfait). Le plugin Groovy pour Eclipse supporte déjà certains refactoring groovy<->java. C'est en réglant cette question du langage d'expression de spec compatible refactoring, que j'entrevois une possible montée en charge des specstests en projet. Et je parie que ça se fera avec les langages sur xVM.
Ces spectests contiennent en effet des centaines de cellules entêtes (ou de mots de phrases, pour BDD) qui correspondent 1 pour 1 à des attributs/paramètres, méthodes, classes java de fixtures (fr. code de liaison). Dans la pratique, le développeur perd bcp trop de temps à établir et réparer cette correspondance : même et surtout en approche "test en premier", la stabilité du test n'est jamais immédiate, les identificateurs - qui correspondent aux concepts manipulés - changent, bougent, se transforment; côté code, le remaniement est aussi fréquemment de mise, pour améliorer la lisibilité du code ou la simplicité du design (on espère pour votre dette technique).
Un outil comme Eclipse apporte la vérification permanente du respect global des identificateurs (merci visual age) et la facilité de remaniement à 1 seul point pour tous (merci intellij) entre "java et java" pourrait on dire ; le développeur est habitué; il aimerait légitimement avoir la même chose entre specstests et codes de liaison.
Faire 2 couches bien distinctes ? le "métier" tel que vu par les tests fitnesse (et = identificateurs/signatures des fixtures), et le métier vu par l'appli, 2 "langages", et compensation totale et complète au niveau de l'implementation des fixtures ? C'est faire l'hypothèse trop souvent fausse que les concepts manipulés en spectests sont rapidement stables (sans parler de changement, juste en parlant de maturité de la compréhension du besoin par ex), et c'est "payer" une compensation par un double modèle et beaucoup de lignes de codes sans forte valeur ajoutée, donc coûteuses et risquées à maintenir. Encore une fois, ça ne se voit pas en démo sans pression sur les délais, et ça se voit très vite en condition réelle, contrainte délai, et en concurrence avec toutes les autres choses qu'on a besoin de faire en projet...
si on réfléchit bien, fixture et feuilles stipulent les mêmes identificateurs; ils ne doivent pas correspondre, ce sont les mêmes; pourquoi avoir 2 langages différents ?
Je crois de plus en plus à la nécessité que les langages d'expression de test soient munis de plugins Eclipse compatibles refactoring a minima. Condition requise pour sortir de l'ornière "démo".
Une prédiction ? Je pense que c'est cuit pour un plugin wikitext-fitnesse pour Eclipse : il n'y a pas de culture "langage/arbre syntaxique" dans la sphère fitnesse... Il y en a en revanche dans la sphère des Langages Dynamiques sur xVM; Je crois donc aux filières type Groovy/EasyB pour le cas Java par exemple (je n'ai pas dit que EasyB était parfait). Le plugin Groovy pour Eclipse supporte déjà certains refactoring groovy<->java. C'est en réglant cette question du langage d'expression de spec compatible refactoring, que j'entrevois une possible montée en charge des specstests en projet. Et je parie que ça se fera avec les langages sur xVM.
Commentaires
Des fois aussi la chance vient s'en mêler : je commence un projet de traduction des messages XML qui circulent entre deux applis. Donc là le DSL c'est dire : "J'exécute tel bout de XML qui alimentate la base, le code testé doit envoyer une requête avec tel XML dedans, on va faire semblant d'être le système au bout qui répond ça, et finalement je vérifie que la base contient telle nouvelle entité." Comme tous les mappings d'objets existent déjà ça devrait être du gâteau (hem hem). On peut ajouter des mini-commandes pour simuler une déconnexion brutale de quelque chose.
Le plus gros coup de chance c'est finalement d'avoir des specs ultra-solides pour le format des données manipulées. Donc là pas besoin de refactoring. Pas besoin de langage très spécifique non plus tu me diras parce que les experts fonctionnels parlent le XML couramment.
Peut-être que pour adresser le besoin que tu exprimes dans ton post (supporter le refactoring) il faut concevoir l'appli pour qu'elle offre une API interne qui rende les tests faciles. C'est pas délirant de demander à un expert fonctionnel de produire du code séquentiel avec du typage fort pour le guider.
Ca va, toi ?
c.