Déjà, merci d'aborder le sujet du test logiciel sur ce site et de nous présenter une initiative open source: ce n'est pas si fréquent.
De ce que je comprends, UUV est framework de test orienté mot-clé (keyword driven) qui se destine à des non techniciens ou tout au moins des non programmeurs. Il s'agit de mettre à disposition des directives d'automatisation de tests (des mots clés) au travers d'un langage spécialisé (DSL= Domain Specific Language) proche des langages naturels, par opposition aux langages de programmation. Chaque mot-clé ou phrase dispose d'une implémentation par défaut avec la possibilité de rentrer des paramètres.
Il en existe pléthore sur le marché. Un des plus connu est RobotFramework. Voici un exemple minimaliste
UUV quant à lui adopte un formalisme proche du Gherkin qui assimile souvent ces frameworks au BDD (Behavior Driven Development) alors qu'ils n'en relèvent pas (nous y reviendrons). A la différence de Cucumber ou d'autres comme Gauge, qui séparent les spécifications de leur implémentation, mais laissent le soin à l'équipe de dev/test d'implementer tous les mot-clés en conférant toute latitude dans leur implementation, UUV vient avec ses mot-clés assez bas nveau orientés interface utilisateur plutôt que métier et la possibilité d'étendre le lexique.
Pour ce qui est de l'aspect technique, UUV se destine uniquement aux interfaces Web et permet de s'abstraire de Cypress et Playwright, ce qui est un challenge tant leurs architectures sont différentes (le premier embarque son code dans une Webview et tourne dans la même boucle d'exécution que le code applicatif tandis que le second s'appuie sur un protocole distant en mode connecté qui pilote un navigateur: le Chrome Devtools Protocol, à l'instar de Selenium Webdriver qui utilise ResT). Encore une fois Robotframework ou Karaté le permettent tout en étant encore plus génériques et en permettant d'automatiser les applis natives, mobiles, tester les base de données ou des API ...
Autre différence avec ces 2 frameworks, tout comme Testerum: ils permettent d'appeler récursivement d'autres mot-clés, permettant de structurer son code de test en couches (métier, UI, ...) avant même d'envisager de créer ses propres mots clé avec un langage de programmation et devoir recourir à l'expertise des programmeurs
Plusieurs soucis avec ces frameworks basées sur la syntaxe Gherkin cependant:
Déjà, on ne fait de dévoyer la syntaxe Gherkin qui est intrinsèquement liée à l'approche BDD selon ses concepteurs. Le Behaviour Driven Development est avant tout une méthodologie qui, comme son nom l'indique, entend mener son projet entièrement autour de la notion de comportement, y compris avec les frameworks BDD type Cucumber, et non pas de se transformer en outil de test. Ainsi l'objectif est avant tout de communiquer et collaborer sur les spécifications fonctionnelles en associant tous les acteurs du projet (le métier, le développeur et testeur en tant que rôle) et en raisonnant sur des exemples avec le langage du domaine. Les Example mapping sessions sont un excellent instrument pour ce faire. On peut ainsi illustrer et raisonner sur ces spécifications, les challenger et découvrir ou valider des règles métier avant toute chose, en se concentrant sur le domaine et non sur les interactions homme-machine. De là découle la stratégie du développement qui permet d'implementer le code de l'application et les tests en même avec une un approche descendante (outside in et double boucle TDD : Test d'acceptation -> Test unitaire -> Code ). Ces tests et leur description textuelle sous forme d'exemples deviennent alors de la documentation toujours à jour (living documentation) et des "specifications exécutables" puisqu'on peut les rejouer automatiquement
Il est donc important de se limiter aux règles du métier indépendamment de l'interface utilisateur pour que les examples (tests) restent intelligibles et stables dans le temps. Ceci vient à l'encontre de ces fameux frameworks sachant que l'expressivité et la grammaire de ces langages est très limitée par ailleurs (Given, When Then et des paramètres). On se retrouve donc avec des scenarios illisibles, fragiles et inmaintenables, écrits dans un style impératif, plutôt que déclaratif car couplés à l'interface utilisateur. Le métier ne les consulte plus et les devs/testeurs perdent leur temps à les maintenir avec toutes les contraintes et la perte de temps que ça induit. Bref, on se concentre sur le fait de valider les règles métier et si on suit les bonnes pratiques, on le fait au plus bas niveau possibles où elles s'expriment lorsque c'est possible (l'API ou même le contrôleur, plutôt que le navigateur)
Maintenant à propos des frameworks orientés most clé ou dit low-code:
D'une manière générale, ce qui est vrai pour ces framework basés sur le Gherkin l'est aussi pour tous ces autres frameworks plus génériques dans une moindre mesure. Même si on peut aller assez loin dans l'implémentation de ces tests avec RobotFramework par exemple (structure de contrôle, modularité, variables, ...), on ne bénéficie jamais de la même souplesse ni de la robustesse que des frameworks spécifiquement implémentés pour des langages de programmation, car on ne dispose pas de toutes la puissance de ces derniers (paradigmes OOP, structures de contrôles avancées, ... répertoires de librairies très larges, intégration poussée avec les EDI, debugging et outres outils , ... )
Mon point de vue en guise de conclusion: n'utilisez Cucumber et Gherkin ou un autre framework pur BDD (qui sépare la spec et l'implémentation) uniquement que pour valider et collaborer sur vos règles du domaine avec le metier métier, si nécessaire. Adoptez l'approche BDD sans même ces frameworks lorsque c'est possible et implémentez vos tests avec les mêmes stacks que celle de votre application. Si vous intégrez des testeurs dans vos équipes: un bon automaticien doit savoir coder et enfin restez à distance de ces frameworks low-code dès lors qu'il s'agit d'étendre votre patrimoine de tests.
# Réflexions sur le journal et le projet mis en lumière
Posté par El Titi . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 6.
Déjà, merci d'aborder le sujet du test logiciel sur ce site et de nous présenter une initiative open source: ce n'est pas si fréquent.
De ce que je comprends, UUV est framework de test orienté mot-clé (keyword driven) qui se destine à des non techniciens ou tout au moins des non programmeurs. Il s'agit de mettre à disposition des directives d'automatisation de tests (des mots clés) au travers d'un langage spécialisé (DSL= Domain Specific Language) proche des langages naturels, par opposition aux langages de programmation. Chaque mot-clé ou phrase dispose d'une implémentation par défaut avec la possibilité de rentrer des paramètres.
Il en existe pléthore sur le marché. Un des plus connu est RobotFramework. Voici un exemple minimaliste
UUV quant à lui adopte un formalisme proche du Gherkin qui assimile souvent ces frameworks au BDD (Behavior Driven Development) alors qu'ils n'en relèvent pas (nous y reviendrons). A la différence de Cucumber ou d'autres comme Gauge, qui séparent les spécifications de leur implémentation, mais laissent le soin à l'équipe de dev/test d'implementer tous les mot-clés en conférant toute latitude dans leur implementation, UUV vient avec ses mot-clés assez bas nveau orientés interface utilisateur plutôt que métier et la possibilité d'étendre le lexique.
Beaucoup de frameworks s'inspirent de cette idée avec les mêmes limitations et inconvénients: Karate, Testerum, ... et même avec RobotFramework c'est possible
Pour ce qui est de l'aspect technique, UUV se destine uniquement aux interfaces Web et permet de s'abstraire de Cypress et Playwright, ce qui est un challenge tant leurs architectures sont différentes (le premier embarque son code dans une Webview et tourne dans la même boucle d'exécution que le code applicatif tandis que le second s'appuie sur un protocole distant en mode connecté qui pilote un navigateur: le Chrome Devtools Protocol, à l'instar de Selenium Webdriver qui utilise ResT). Encore une fois Robotframework ou Karaté le permettent tout en étant encore plus génériques et en permettant d'automatiser les applis natives, mobiles, tester les base de données ou des API ...
Autre différence avec ces 2 frameworks, tout comme Testerum: ils permettent d'appeler récursivement d'autres mot-clés, permettant de structurer son code de test en couches (métier, UI, ...) avant même d'envisager de créer ses propres mots clé avec un langage de programmation et devoir recourir à l'expertise des programmeurs
Plusieurs soucis avec ces frameworks basées sur la syntaxe Gherkin cependant:
Déjà, on ne fait de dévoyer la syntaxe Gherkin qui est intrinsèquement liée à l'approche BDD selon ses concepteurs. Le Behaviour Driven Development est avant tout une méthodologie qui, comme son nom l'indique, entend mener son projet entièrement autour de la notion de comportement, y compris avec les frameworks BDD type Cucumber, et non pas de se transformer en outil de test. Ainsi l'objectif est avant tout de communiquer et collaborer sur les spécifications fonctionnelles en associant tous les acteurs du projet (le métier, le développeur et testeur en tant que rôle) et en raisonnant sur des exemples avec le langage du domaine. Les Example mapping sessions sont un excellent instrument pour ce faire. On peut ainsi illustrer et raisonner sur ces spécifications, les challenger et découvrir ou valider des règles métier avant toute chose, en se concentrant sur le domaine et non sur les interactions homme-machine. De là découle la stratégie du développement qui permet d'implementer le code de l'application et les tests en même avec une un approche descendante (outside in et double boucle TDD : Test d'acceptation -> Test unitaire -> Code ). Ces tests et leur description textuelle sous forme d'exemples deviennent alors de la documentation toujours à jour (living documentation) et des "specifications exécutables" puisqu'on peut les rejouer automatiquement
Il est donc important de se limiter aux règles du métier indépendamment de l'interface utilisateur pour que les examples (tests) restent intelligibles et stables dans le temps. Ceci vient à l'encontre de ces fameux frameworks sachant que l'expressivité et la grammaire de ces langages est très limitée par ailleurs (Given, When Then et des paramètres). On se retrouve donc avec des scenarios illisibles, fragiles et inmaintenables, écrits dans un style impératif, plutôt que déclaratif car couplés à l'interface utilisateur. Le métier ne les consulte plus et les devs/testeurs perdent leur temps à les maintenir avec toutes les contraintes et la perte de temps que ça induit. Bref, on se concentre sur le fait de valider les règles métier et si on suit les bonnes pratiques, on le fait au plus bas niveau possibles où elles s'expriment lorsque c'est possible (l'API ou même le contrôleur, plutôt que le navigateur)
Il suffit de relire le blog même de Cucumber pour comprendre comme cet outil a été mal utilisé.
Maintenant à propos des frameworks orientés most clé ou dit low-code:
D'une manière générale, ce qui est vrai pour ces framework basés sur le Gherkin l'est aussi pour tous ces autres frameworks plus génériques dans une moindre mesure. Même si on peut aller assez loin dans l'implémentation de ces tests avec RobotFramework par exemple (structure de contrôle, modularité, variables, ...), on ne bénéficie jamais de la même souplesse ni de la robustesse que des frameworks spécifiquement implémentés pour des langages de programmation, car on ne dispose pas de toutes la puissance de ces derniers (paradigmes OOP, structures de contrôles avancées, ... répertoires de librairies très larges, intégration poussée avec les EDI, debugging et outres outils , ... )
Mon point de vue en guise de conclusion: n'utilisez Cucumber et Gherkin ou un autre framework pur BDD (qui sépare la spec et l'implémentation) uniquement que pour valider et collaborer sur vos règles du domaine avec le metier métier, si nécessaire. Adoptez l'approche BDD sans même ces frameworks lorsque c'est possible et implémentez vos tests avec les mêmes stacks que celle de votre application. Si vous intégrez des testeurs dans vos équipes: un bon automaticien doit savoir coder et enfin restez à distance de ces frameworks low-code dès lors qu'il s'agit d'étendre votre patrimoine de tests.