Ç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 Guillaume Knispel . En réponse au journal Du concombre et du cornichon. É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.