Il est clair que sur le ton accusateur utilisé n'est pas du tout approprié à mon sens. Je vais le mettre de côté pour pouvoir te répondre.
Si on intervertit les textes de app-title et start-button, le test programmeur et utilisateur ne passeront pas tous les 2, parce que le test utilisateur ici s'appuie sur des tests programmeurs, comme UUV va venir en abstraction par rapport à cypress dans cette exemple ou playwright.
"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 vrai lorsqu'on utilise le prisme de développeur, celui que tu utilises dans tes analyses et qui t'obliges à associer forcément le mot test à ton contexte que tu connais bien, je suppose qui est le développement. Je t'invite à consulter cette vidéo nommée Revisitons tous nos a prioris sur le(s) test(s) - Christophe Thibaut visible sur chaîne de test pour adapter ton prisme d'analyse si tu le souhaites.
Ici 2 prismes sont utilisés le premier est celui de la maximisation de la qualité produit en diversifiant les tests par plusieurs acteurs du logiciel autres que les développeurs et les testeurs. Le second est maximiser la qualité de données, restituée à nos utilisateurs y compris ceux qui utilisent des outils d'assistance et ce en proposant une posture proactive plutôt que réactive concernant l'accessibilité numérique.
start-button n'a pas été rajouté par hasard
effectivement, peut être que ça a été rajouté par un habitus de développeur qui n'a eu qu'à sa disposition que des outils techniques ou qui reproduit ce qu'il sait faire. Peut être que derrière le start-button, il y a plutôt un lien et que l'identifiant est mal nommé et que ça peut induire en erreur d'autres développeurs qui ne sont pas dans la devTeam et qui vont tester l'application parce qu'ils sont mandatés côté métiers?
Qui vérifie que ce bouton est bien un bouton? Qui vérifie que l'id start-button est renommé en cancel-button, si le libellé du bouton est renommé en cancel?
La solution va permettre de vérifier les informations liées à l'accessibilité en plus des autres aspects et rajoute une couche de vérification niveau produit pour les cas où les développeurs seraient en surmenage par exemple.
Typescript permet beaucoup de tests, et à ma connaissance ce n'est pas la première fois qu'on essaye des "User centric Usecases Validator"
il faut prendre conscience que la solution adresse les personnes non techniques d'un projet en utilisant cucumber (c'est bien la volonté de Seb Rose le créateur de cucumber), si tu n'admets pas cet aspect, c'est que tu n'acceptes pas non plus la philosophie de cucumber qui est adoptée par pas mal de projets maintenant. Moi personnellement, je pense que ça a du bon, ça ne permets pas de tout faire, ce n'est pas la volonté d'avoir une stratégie de test en cornet de glace, mais ça donne l'opportunité à plus de monde de faire des choses sans maîtriser la technique :-)
Ton point 3 commence déjà à montrer des limitations du "langage naturel", ça parle anglais tout le temps sauf bam un JSON pas naturel du tout
ça devient intéressant. C'est effectivement une limitation forte de ce langage, qui n'est pas destiné à tout tester, mais peut être qu'ici la forme employée n'est pas la bonne, c'est une phrase très technique à vrai dire et je pense qu'on peut mieux faire, comme c'est open source, tu peux faire une PR pour proposer quelque chose de plus pertinent. Toutefois, dans cet exemple, l'approche usercentric pour effectuer des vérifications d'accessibilité normalisées par un référentiel et une codification qui lui est propre, n'a pas réellement de sens.
le terme de hors sujets, c'est ce que tu décides de mettre en hors sujet, car les propos évoqués ne sont pas hors sujets par rapport à l'article qui est d'analyser 3 mauvaises pratiques, ou erreurs courantes, qui limitent la pertinence des tests E2E.
Si le but était de faire réellement la promotion de UUV, l'article aurait été écrit différemment je pense.
Pour finir pour les comparaisons entre cypress et UUV, voici deux liens qui pointent sur 2 katas attaquant la même application.
- cypress
- UUV
[^] # Re: Tests différents (ou partiels)
Posté par stanlee974 (site web personnel) . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 5.
Hello !
Il est clair que sur le ton accusateur utilisé n'est pas du tout approprié à mon sens. Je vais le mettre de côté pour pouvoir te répondre.
Si on intervertit les textes de app-title et start-button, le test programmeur et utilisateur ne passeront pas tous les 2, parce que le test utilisateur ici s'appuie sur des tests programmeurs, comme UUV va venir en abstraction par rapport à cypress dans cette exemple ou playwright.
c'est vrai lorsqu'on utilise le prisme de développeur, celui que tu utilises dans tes analyses et qui t'obliges à associer forcément le mot test à ton contexte que tu connais bien, je suppose qui est le développement. Je t'invite à consulter cette vidéo nommée
Revisitons tous nos a prioris sur le(s) test(s) - Christophe Thibautvisible sur chaîne de test pour adapter ton prisme d'analyse si tu le souhaites.Ici 2 prismes sont utilisés le premier est celui de la
maximisation de la qualité produiten diversifiant les tests par plusieurs acteurs du logiciel autres que les développeurs et les testeurs. Le second estmaximiser la qualité de données, restituée à nos utilisateurs y compris ceux qui utilisent des outils d'assistance et ce en proposant une posture proactive plutôt que réactive concernant l'accessibilité numérique.effectivement, peut être que ça a été rajouté par un
habitus de développeurqui n'a eu qu'à sa disposition que des outils techniques ou qui reproduit ce qu'il sait faire. Peut être que derrière lestart-button, il y a plutôt unlienet que l'identifiant est mal nommé et que ça peut induire en erreur d'autres développeurs qui ne sont pas dans la devTeam et qui vont tester l'application parce qu'ils sont mandatés côté métiers?Qui vérifie que ce
boutonest bien unbouton? Qui vérifie que l'idstart-buttonest renommé en cancel-button, si le libellé du bouton est renommé en cancel?La solution va permettre de vérifier les informations liées à l'accessibilité en plus des autres aspects et rajoute une couche de vérification niveau produit pour les cas où les développeurs seraient en surmenage par exemple.
il faut prendre conscience que la solution adresse les personnes non techniques d'un projet en utilisant cucumber (c'est bien la volonté de Seb Rose le créateur de cucumber), si tu n'admets pas cet aspect, c'est que tu n'acceptes pas non plus la philosophie de cucumber qui est adoptée par pas mal de projets maintenant. Moi personnellement, je pense que ça a du bon, ça ne permets pas de tout faire, ce n'est pas la volonté d'avoir une stratégie de test en cornet de glace, mais ça donne l'opportunité à plus de monde de faire des choses sans maîtriser la technique :-)
ça devient intéressant. C'est effectivement une limitation forte de ce langage, qui n'est pas destiné à tout tester, mais peut être qu'ici la forme employée n'est pas la bonne, c'est une phrase très technique à vrai dire et je pense qu'on peut mieux faire, comme c'est open source, tu peux faire une PR pour proposer quelque chose de plus pertinent. Toutefois, dans cet exemple, l'approche usercentric pour effectuer des vérifications d'accessibilité normalisées par un référentiel et une codification qui lui est propre, n'a pas réellement de sens.
le terme de
hors sujets, c'est ce que tu décides de mettre en hors sujet, car les propos évoqués ne sont pas hors sujets par rapport à l'article qui est d'analyser 3 mauvaises pratiques, ou erreurs courantes, qui limitent la pertinence des tests E2E.Si le but était de faire réellement la promotion de UUV, l'article aurait été écrit différemment je pense.
Pour finir pour les comparaisons entre cypress et UUV, voici deux liens qui pointent sur 2 katas attaquant la même application.
- cypress
- UUV
En espérant avoir répondu à tes questionnements.