cucumber et gherkin, cela vous dit quequechose?
Si tel n'est pas le cas, sachez qu'il s'agit là de traduire un scénario de test écrit en langage naturel en des actions techniques.
Nous sommes là dans le monde du BDD, le "Behavioral Driven Development" paraît-il.
En bref, je propose aujourd'hui une modeste solution pour traduire la syntaxe Gherkin en commandes selenium, et ceci sans langage de dev tel que java, js ou ruby. Rien de tout cela, juste du shell.
Le bénéfice est de pouvoir se lancer dans l'automatisation de tests de sites web (tests "end2end"), sans pour autant savoir faire du dev. Ça devrait pouvoir aider des testeurs en mode manuel à rattraper le train de l'automatisation ou "DevOps".
Voici le lien:
http://devopsfr.ovh/cucumber-version-bash/
# sans pour autant savoir faire du dev
Posté par Victor . Évalué à 2. Dernière modification le 27 mai 2018 à 12:13.
C'est un peu osé comme assertion, non ?
La difficulté du dev, c'est pas le langage, c'est d'exprimer des programmes, donc si tu passes du ruby au shell, bah, ça change rien au problème (et puis le shell est ptete pire à utiliser, quand je vois les exemples que tu donnes).
Edit : après réflexion je me dis que j'ai peut-être pas bien compris ce que fait ton truc sinon
[^] # Re: sans pour autant savoir faire du dev
Posté par barmic . Évalué à 1.
Non son assertion est juste. L'objectif est d'exprimer les tests d'acceptance d'un logiciel dans un langage proche dun langage naturel. Le principe du BDD est de permettre de décrire les tests via des phrases structurées.
[^] # Re: sans pour autant savoir faire du dev
Posté par Victor . Évalué à 3.
Oui BDD "permet" ça, c'est vrai, mais dans la limite du possible en pratique, car au final, on doit passer de l'expression du test en du code en transformant chacune des "features" du test en un appel de code, et quelqu'un doit l'écrire ce code.
Son assertion semblait dire que c'était son outil qui permettait de faire ça sans langage de dev, et du peu que j'ai compris, grâce à du shell. Et c'est ça qui me fait tiquer :)
[^] # Re: sans pour autant savoir faire du dev
Posté par G.bleu (site web personnel) . Évalué à 2.
Sur le sujet je conseil l'article de Sam&Max sur le BDD: http://sametmax.com/lettuce-and-cucumber-is-bullshit/
Le ton est caustique (après tout c'est pour ça qu'on les aime !) mais le fond est intéressant ;-)
[^] # Re: sans pour autant savoir faire du dev
Posté par NicolasP . Évalué à 4.
Le fond de l'article part du postulat que ce sont les développeurs qui vont écrire les tests en gherkin.
Sur un projet sur lequel je suis, ce sont des fonctionnels qui ne savent pas écrire une ligne de code qui écrivent le gherkin. Et évidemment eux ils ne vont pas tester le statut d'une chaîne de tâches asynchrones. Ils vont tester "est-ce que quand je mets 'toto' dans le champ 'nom' et que je clique sur 'valider', ça m'affiche bien une page de confirmation dans laquelle j'ai une url vers bidule truc". Je schématise mais le principe c'est que eux vont faire les tests métiers plus ou moins de bout en bout. Les tests unitaires restent à la charge des développeurs (et ne sont pas faits avec du Gherkin).
Pour ce qui est de la motivation, ça a été très simple : soit ils font leurs tests à la main à chaque mise en prod, soit ils utilisent ça. Ils ont choisi de leur plein gré et ont été moteurs quant aux choix des "phrases" que les développeurs leur ont mis à disposition.
[^] # Re: sans pour autant savoir faire du dev
Posté par Guillaume Knispel . Évalué à 4.
Ça reste par définition un langage de prog, et donc des lignes de code. Dans un langage assez peu pratique pour faire des lignes de code, mais des lignes de code quand même.
Des tentatives proches de créer de tels langages prétendument pour les moins "techniques", voire pour les non techniques, ont ponctué l'histoire de l'informatique y compris à ses tous débuts, avec invariablement le résultat le plus prévisible qui soit, qui est qu'on a juste au final un très mauvais langage peu adapté vu qu'il est invariablement peu expressif, peu puissant, et/ou peu précis pour ce qu'on en fait, utilisé par des testeurs (dans ce cas, mais ça peut aussi être développeur, selon les langages) qui ne s'en servent pas de manière juste occasionnelle, donc qui passent du temps à faire tout cela, et qui donc pourraient et devraient investir ce temps à apprendre un vrai langage (au début de l'histoire de l'info y avait parfois pas d'autre choix, mais on a fait des progrès depuis…)—de toute manière leur technicité va forcement augmenter sauf que là on les fait apprendre un truc de niche avec tous les inconvénients que j'ai cité, au lieu de leur faire apprendre des trucs puissants généralisables dans d'autres domaines - voire même intrinsèquement plus puissants pour faire de meilleurs tests couvrant plus.
Alors évidement ça fonctionne quand même. Tout comme le Cobol a fonctionné au point qu'on en a encore en quantité astronomique. Est-ce que son pari de simplifier l'info en écrivant des conneries à là "ADD NUM1 TO NUM2" au lieu de NUM1 += NUM2 a permis, pour faire un parallèle, à des "fonctionnels qui ne savent pas écrire une ligne de code" de comprendre la programmation ? Je ne crois pas. Je ne crois pas non plus que les projets de tests utilisant le Gherkin qui réussissent le fassent grâce au Gherkin.
[^] # Re: sans pour autant savoir faire du dev
Posté par NicolasP . Évalué à 2.
Non. Ou alors il te faut une définition de langage de programmation très large. Il n'y a par exemple aucune possibilité de faire des branchements conditionnels ni aucune structure de données (hormis une variable tampon car ils ont la possibilité de faire des copier/coller), … On est très très loin du turing compliant.
On ne l'utilise pas pour faire de l'algorithmie, juste pour décrire de manière formelle des actions à répéter bêtement et méchamment.
[^] # Re: sans pour autant savoir faire du dev
Posté par StyMaar . Évalué à 2.
Alors, c'est du pinaillage mais ce que tu cherches à dire c'est «Turing complet», qui est un concept mathématique. Le mot “compliant” est un anglicisme qui s'emploie quand on veut parler de la conformité à un standard : tu peux dire POSIX-compliant par exemple.
[^] # Re: sans pour autant savoir faire du dev
Posté par barmic . Évalué à 3.
Effectivement, mais il rempli un besoin qu'ils ont et qu'ils ne pourraient pas remplir autrement.
Le BDD c'est une méthodologie pas une technique. Ça correspond à un processus, une façon de faire. Notamment il y a le principe des "3 amigos" : un expert du domaine, un testeur et un dev qui se mettent d'accord sur les critères d'acceptance. Le fait que ces 3 acteurs soient en mesure d'écrire et de comprendre les critères est vraiment pratique. Le fait qu'il n'y a pas de d'étapes pour passer de ses critères aux tests exécutés est presque nécessaire sinon tu peux jeter tes critères car ils ne seront jamais à jour donc jamais lisibles par un expert du domaine.
C'est un problème général. Quand on parle des techniques issues du DDD (Domain Driven Design). Les dev s'intéressent à la technique et oublie le processus qui va avec. C'est vraiment regarder le sujet par le petit bout de la lorgnette. Tu as le même point quand il est question de CQRS ou d'Event Sourcing. Les gens oublient de définir par exemple ce qu'est un agrégat (entre autre).
[^] # Re: sans pour autant savoir faire du dev
Posté par El Titi . Évalué à 2.
Une autre aspect important est aussi la documentation vivante ("living documentation").
Tes tests (le code de test) sont liés à tes scénarios d'exemple. Modifier les scénarios peut casser le code et un changement sur le code est répercuté sur les tests d'intégrations au travers de ces scénarios.
On rompt avec l'écueil de toutes les approche d'ingénierie dirigée par les modèles
et dans lesquels le modèle (qui constitue la spec) sert à générer le code et finit par ne plus être son reflet car on ne remonte plus les changements au niveau du modèle lorsque le code évolue.
[^] # Re: sans pour autant savoir faire du dev
Posté par barmic . Évalué à 1.
C'est ce que je voulais exprimer en disant :
[^] # Re: sans pour autant savoir faire du dev
Posté par El Titi . Évalué à 2.
C'est la où tu méprends légèrement.
Tu confonds les DSL (Domain Specific Languages) textuels/graphiques et les autres langage plus généraux( UML & Co) avec le BDD.
Le principe du BDD est juste de s'appuyer sur une idée de bon sens que tout le monde applique de lui-même.
"Un exemple vaut mieux qu'un long discours".
Le livre fondateur:
https://www.amazon.com/Specification-Example-Successful-Deliver-Software/dp/1617290084/ref=sr_1_1?s=books&ie=UTF8&qid=1455777095&sr=1-1&keywords=specification+by+example
La syntaxe Gherkin (Given … When… Then… qui ressemmble étrangement au AAA -Arrange Act Assert d'un TU digne de ce nom au passage d'ou des frameworks TU à la http://spockframework.org/) est simplissime et n'est absolument pas ogligatoire pour faire du BDD.
Voici par exemple 2 frameworks qui ne requièrent pas l'usage de Gherkin et laissent exprimer les scénarios d'exemple au format libre (ce qui n'exclue pas des conventions dans une équipe)
https://gauge.org/
http://concordion.org/tutorial/java/markdown/
Et comme illustré dans un autre lien pointé plus haut (example mapping session) ce qui est demandé au client (et en collaboration avec lui) c'est juste de déterminer les exemples (les titres des scénarios). Le travail d'écriture des scénarios textuels et leur implem est laissé à la main de la dev team. Il sera demandé au client de relire ces scénarios (facilement compréhensibles pour le coup) et d'en rediscuter s'ili reste des zones d'ombres. Chaque acteur du projet (PO, QA et dev) appréhende du coup le métier plus précisément selon sa perspective.
[^] # Re: sans pour autant savoir faire du dev
Posté par El Titi . Évalué à 3.
Les articles de Sam sont en général très intéressants, mais dans le cas présent j'ai comme un"léger" doute sur sa bonne foi … ou ses compétences.
Le monsieur a sorti des exemples jouets tirés des frameworks qui évidemment ciblent des cas facilement implémentables sous forme de test unitaires alors que les tests concernés par le BDD sont en général des tests d'integration ou end to end (boîte noire) .
Visiblement beaucoup de concepts lui ont échappé dans le BDD et en particulier sa finalité qui est avant tout de récupérer des bonnes specs tirées d'exemples, ce qui permet de mettre tout le monde autour d'une table (les 3 amigos, "product owner", testeurs et devteam https://cucumber.io/blog/2015/12/08/example-mapping-introduction )
et de parler dans le langage du client (ubiquitous language). Ceci se retranscrit jusque dans le code et l'archi (Domani Driven Design)
https://blog.xebia.fr/2009/01/28/ddd-la-conception-qui-lie-le-fonctionnel-et-le-code/
Les tests autos ne sont qu'un "effet de bord" de l'approche
Il oublie allègrement la double boucle BDD (tests d'acceptation et TUs en même temps que le code) et en déduit que c'est de la merde parce que dans SON taf il n'en pas besoin. Un bel homme de paille en python
http://coding-is-like-cooking.info/2013/04/outside-in-development-with-double-loop-tdd/
Bref pour reprendre son ton cynique: "Il dit de la merde et ferait mieux de pas l'ouvrir sur tout et nimportnawak". Un tampon "Gros boulet" qui se perd
[^] # Re: sans pour autant savoir faire du dev
Posté par El Titi . Évalué à 3.
Pour en finir avec le sieur, il est beaucoup plus à l'aise sur son terrain de jeu: les TUs et ce petit guide en 4 parties http://sametmax.com/un-gros-guide-bien-gras-sur-les-tests-unitaires-en-python-partie-1/ est une excellente entrée en matière pour ceux qui voudraient s'y mettre en python.
Sachant que pour les test d'acceptation en python (ATDD/BDD) Robot est un excellent complément:
http://robotframework.org/
Et pour ceux qui voudraient mieux comprendre cette approche en double boucle (à la old school sans framework ça marche aussi) un exemple en java très instructif:
https://www.infoq.com/articles/atdd-from-the-trenches
[^] # Re: sans pour autant savoir faire du dev
Posté par pizaninja . Évalué à 1.
Tu as raison.
Le shell, ça reste une forme de dev.
Disons qu'au moins, c'est directement accessible:
- pas besoin d'installer de jvm, nodejs, gem, etc…
- pas besoin de phase de build
Tu parles de shell pire que les autres langages dans mes exemples. Est-ce à cause de ma façon de coder?
Le plus important de mon point de vue est que l'écriture des "step definitions" est très similaire de ruby au shell:
- une regexp
- une commande/assertion à lancer
[^] # Re: sans pour autant savoir faire du dev
Posté par Victor . Évalué à 2.
Non pas du tout, tu as bien souligné ce que je voulais dire, c'est juste qu'il y a un langage à apprendre qui possède un côté "algorithmique" :)
[^] # Commentaire supprimé
Posté par pizaninja . Évalué à 1. Dernière modification le 28 mai 2018 à 07:42.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # ???
Posté par pizaninja . Évalué à 1.
Mince, qu'ai-je dit qui nécessitait une modération ?
[^] # Re: ???
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Un doublon de https://linuxfr.org/users/pizaninja/journaux/du-concombre-et-du-cornichon#comment-1740096
# licence
Posté par Psychofox (Mastodon) . Évalué à 0.
Et la licence ? c'est quoi ces scripts propriétaires. _^
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.