Merci pour ce cas d'exemple. Le but de l'auteur je pense, n'est pas de dire faite tout avec UUV ou vous pouvez tout faire avec UUV, mais plutôt : hey, il existe une alternative supplémentaire si vous voulez adresser un public plus large d'utilisateurs. A mon sens aucune solution au monde ne permet de tout faire :-) donc pour n'importe quelle solution il y a des cas qu'on ne peut pas gérer. Il faut donc soit switcher de solution, soit tester différemment.
UUV aborde une approche usercentric et se base sur les données accessibles pour requêter le DOM HTML.
Je l'ai dit dans un autre commentaire, le prisme de réflexion utilisé est celui de l'accessibilité pour être proactif plutôt que réactif sur le sujet, et le 2ème c'est qualité du produit en donnant la possibilité à plus d'acteurs du logiciels de tester.
Le test automatisé teste ce qui est facilement automatisable. Si c'est difficilement automatisable, il faut aller sur un test manuel ou un autre type de test. En aucun cas on ne peut préconiser de tout automatiser. Cela dit, dans ton cas, il y a des choses automatisable à mon sens. Déjà, comme toute application il faut rendre son application testable par rapport au framework de test qu'on utilise. C'est une vérité, si on veut faire un TU sur une méthode avec par exemple Junit, et qu'on a repository qui va taper une BDD, on va peut être mettre une interface ou je ne sais quoi en injection pour pouvoir faire un fake ou le mocker par exemple (si on ne la pas fait dès le départ).
Si on est en E2E et qu'on utilise cypress avec la volonté de tester un élément de DOM, on va rajouter un data-testid pour le récupérer. Donc déjà on a cette phase de rendre le code testable qui est faite naturellement par les dev qui font du test sans même s'en rendre compte tellement c'est naturelle. Ici avec UUV, comme ça se base sur l'accessibilité, il faut bien faire le nécessaire pour que les informations accessibles soient bien valorisées.
Après quand on parle de E2E sur un front, il y a plusieurs config:
- celle dans laquelle tu testes que le front isolé du back,
- celle dans laquelle tu testes ton front et ton back isolés des partenaire externes,
- celle dans laquelle tu testes ton système dans son ensemble comme une app en production.
Dans le cas que tu évoques c'est plutôt ce 3ème cas.
Celui que l'auteur évoque c'est plutôt le 1er ou 2ème cas car ils sont suffisants pour valider les 2 objectifs de UUV.
Ensuite, il faut se mettre dans un mindset où on se décorrèle des briques techniques que tu évoques. Je vais m'expliquer.
Le test commande par piloter le tunnel de vente pour commander un pizza, il faut déjà interagir avec le SSO basé sur keycloak en fédération d'identité avec Fatbook (le réseau social des gros mangeurs) qui propose du MFA par SMS => il faut comprendre openid connect et pouvoir appeler des API pour envoyer et recevoir des SMS ;
les couches techniques évoquées ici, peuvent être testées avec des tests de plus bas niveau comme des TU ou des tests d'intégration ou encore des tests manuels par exemple. Toute solution de test E2E sera en galère face à ce scénario si on ne rend pas la solution dans son écosystème testable en E2E. Donc les difficultés que tu évoques existent sur toutes les solutions E2E autres que UUV.
Toutefois, il peut être fait avec des automates si on veut vraiment le faire, si ceux-ci ont accès aux devices ou à des serveurs qui vont faire office de devices.
Les systèmes d'authent ont des mécanismes qui existent pour bypasser au niveau des tests, donc ceux-ci peuvent être utiliser, mais la pertinence du test est forcément impacté dans ce cas, si ton objectif est de tester le système dans son ensemble.
Je pense que le coeur de cible de UUV ou des tests E2E, n'est pas ce genre de use case.
il faut tester que le backoffice de réception des commandes en cuisine, celui-ci n'est pas accessible sur internet, le testeur doit déployer l'appli sur un serveur de test => Dave Ops est en congé, mais il a laissé les scripts Opentofu et Ansible avec un post it "tu verras c'est simple" ;
J'ai un peu répondu plus haut, tu peux rajouter plein de difficulté inhérent à des cas exceptionnels. Si tu veux faire des choses, il faut se donner les moyens de le faire. Si un projet veut faire du test E2E, il faut qu'il rende son produit testable et donc l'env doit être fait avant que Dave soit en congé. Sinon c'est un peu comme espérer gagner à l'euromillions sans avoir joué de ticket.
lorsque le livreur prends son skateboard, la puce IoT de ce dernier envoie un message qui est enregistré dans une base d'audit, il n'existe pas d'API pour y accéder => il faut donc taper la base directement en sql ;
Ici encore une fois, le produit n'est pas testable, même la feature n'est pas testable, que ce soit en TU, en test d'intégration ou E2E, donc il faut faire le nécessaire avant de se lancer dans les tests. Normalement la stratégie de test, est quelque chose qui doit se réfléchir avant que le projet se lance, tout comme les apsect sécu, tracing, archi logiciel, système. Malheureusement c'est fait que trop tard et ces situations peuvent exister.
[^] # Re: Formation ?
Posté par stanlee974 (site web personnel) . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 4.
Hello !
Merci pour ce cas d'exemple. Le but de l'auteur je pense, n'est pas de dire faite tout avec UUV ou vous pouvez tout faire avec UUV, mais plutôt : hey, il existe une alternative supplémentaire si vous voulez adresser un public plus large d'utilisateurs. A mon sens aucune solution au monde ne permet de tout faire :-) donc pour n'importe quelle solution il y a des cas qu'on ne peut pas gérer. Il faut donc soit switcher de solution, soit tester différemment.
UUV aborde une approche usercentric et se base sur les données accessibles pour requêter le DOM HTML.
Je l'ai dit dans un autre commentaire, le prisme de réflexion utilisé est celui de l'accessibilité pour être proactif plutôt que réactif sur le sujet, et le 2ème c'est qualité du produit en donnant la possibilité à plus d'acteurs du logiciels de tester.
Le test automatisé teste ce qui est facilement automatisable. Si c'est difficilement automatisable, il faut aller sur un test manuel ou un autre type de test. En aucun cas on ne peut préconiser de tout automatiser. Cela dit, dans ton cas, il y a des choses automatisable à mon sens. Déjà, comme toute application il faut rendre son application testable par rapport au framework de test qu'on utilise. C'est une vérité, si on veut faire un TU sur une méthode avec par exemple Junit, et qu'on a repository qui va taper une BDD, on va peut être mettre une interface ou je ne sais quoi en injection pour pouvoir faire un fake ou le mocker par exemple (si on ne la pas fait dès le départ).
Si on est en E2E et qu'on utilise cypress avec la volonté de tester un élément de DOM, on va rajouter un data-testid pour le récupérer. Donc déjà on a cette phase de rendre le code testable qui est faite naturellement par les dev qui font du test sans même s'en rendre compte tellement c'est naturelle. Ici avec UUV, comme ça se base sur l'accessibilité, il faut bien faire le nécessaire pour que les informations accessibles soient bien valorisées.
Après quand on parle de E2E sur un front, il y a plusieurs config:
- celle dans laquelle tu testes que le front isolé du back,
- celle dans laquelle tu testes ton front et ton back isolés des partenaire externes,
- celle dans laquelle tu testes ton système dans son ensemble comme une app en production.
Dans le cas que tu évoques c'est plutôt ce 3ème cas.
Celui que l'auteur évoque c'est plutôt le 1er ou 2ème cas car ils sont suffisants pour valider les 2 objectifs de UUV.
Ensuite, il faut se mettre dans un mindset où on se décorrèle des briques techniques que tu évoques. Je vais m'expliquer.
les couches techniques évoquées ici, peuvent être testées avec des tests de plus bas niveau comme des TU ou des tests d'intégration ou encore des tests manuels par exemple. Toute solution de test E2E sera en galère face à ce scénario si on ne rend pas la solution dans son écosystème testable en E2E. Donc les difficultés que tu évoques existent sur toutes les solutions E2E autres que UUV.
Toutefois, il peut être fait avec des automates si on veut vraiment le faire, si ceux-ci ont accès aux devices ou à des serveurs qui vont faire office de devices.
Les systèmes d'authent ont des mécanismes qui existent pour bypasser au niveau des tests, donc ceux-ci peuvent être utiliser, mais la pertinence du test est forcément impacté dans ce cas, si ton objectif est de tester le système dans son ensemble.
Je pense que le coeur de cible de UUV ou des tests E2E, n'est pas ce genre de use case.
J'ai un peu répondu plus haut, tu peux rajouter plein de difficulté inhérent à des cas exceptionnels. Si tu veux faire des choses, il faut se donner les moyens de le faire. Si un projet veut faire du test E2E, il faut qu'il rende son produit testable et donc l'env doit être fait avant que Dave soit en congé. Sinon c'est un peu comme espérer gagner à l'euromillions sans avoir joué de ticket.
Ici encore une fois, le produit n'est pas testable, même la feature n'est pas testable, que ce soit en TU, en test d'intégration ou E2E, donc il faut faire le nécessaire avant de se lancer dans les tests. Normalement la stratégie de test, est quelque chose qui doit se réfléchir avant que le projet se lance, tout comme les apsect sécu, tracing, archi logiciel, système. Malheureusement c'est fait que trop tard et ces situations peuvent exister.