Il est écrit en Typescript : Il n’est donc pas facile à comprendre pour les personnes qui ne développent pas (on entend ici toute personne qui ne comprend pas du code de programmation), et c’est un peu dommage, car il est censé représenter un cas d’utilisation réel.
Et on s'en fout en fait, le test est pour vérifier que le développeur ne casse rien lors d'une PR, le test est certes sur une UI mais pour le programmeur par le programmeur pour ne rien casser pendant un développement.
C'est plus subtile que ça. Tu parle de tests unitaires qui sont des outils de développeurs pour développeur. Gherkin (cette syntaxe à base de given/when/then) est plutôt faite pour écrire des tests d'acceptantes. Donc c'est pas le développeur qui les écris ou en tout cas pas celui qui écris le code et il ne sont pas à destination des développeurs.
Bref, Typescript permet beaucoup de tests, et à ma connaissance ce n'est pas la première fois qu'on essaye des "User centric Usecases Validator" et qu'à chaque fois au bout d'un moment on revient à des trucs plus "programmeur" car une PR a cassé un truc qu'on n'avait pensé tester avec UUV blabla mais qu'en fait le test était pas assez poussé et que le UUV blabla ne permet pas de faire ce test.
Beaucoup de bibliothèques de tests se rapprochent d'une manière ou d'une autre de construction à la gherkin et des outils comme cypress ou playwright ont rendent relativement accessible ces formalismes et ces méthodologies.
Après je trouve que créer une opposition développeur utilisateur vaine et non pertinentes. Gherkin n'est qu'une syntaxe elle permet de rendre plus fin l'écart qu'il y a entre une spécification et le code. L'objectif de ces approches doivent être de créer des ponts pas des oppositions. L'objectif de gherkin c'est de faire collaborer plus étroitement les gens en augmentant la part de formalisme du côté de la spécification et en ayant une forme de test plus lisible par un non technicien.
[^] # Re: Tests différents (ou partiels)
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 8.
C'est plus subtile que ça. Tu parle de tests unitaires qui sont des outils de développeurs pour développeur. Gherkin (cette syntaxe à base de given/when/then) est plutôt faite pour écrire des tests d'acceptantes. Donc c'est pas le développeur qui les écris ou en tout cas pas celui qui écris le code et il ne sont pas à destination des développeurs.
Beaucoup de bibliothèques de tests se rapprochent d'une manière ou d'une autre de construction à la gherkin et des outils comme cypress ou playwright ont rendent relativement accessible ces formalismes et ces méthodologies.
Après je trouve que créer une opposition développeur utilisateur vaine et non pertinentes. Gherkin n'est qu'une syntaxe elle permet de rendre plus fin l'écart qu'il y a entre une spécification et le code. L'objectif de ces approches doivent être de créer des ponts pas des oppositions. L'objectif de gherkin c'est de faire collaborer plus étroitement les gens en augmentant la part de formalisme du côté de la spécification et en ayant une forme de test plus lisible par un non technicien.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll