Dans ton 1, tu proposes de changer un test "programmeur" par un test "utilisateur" mais tu oublies la moitié du test "programmeur", ton test "utilisateur" sera valide sur la PR intervertit les textes de 'app-title' et 'start-button', pas le test "programmeur".
tu écris :
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.
Utilisation de testId : les testIds sont des attributs ajoutés par les développeurs pour faciliter la localisation des éléments de la page lors des tests.
Yep, et ces testIds (euh... Perso c'était pas ajouté pour le fun, l'ID 'start-button' est utilisé ensuite pour raison X ou Y dans le code JS, par exemple le désactiver si un champs n'est pas rempli) ont une autre finalité dans le test, tu n'as pas montré dans ton test "utilisateur" comment tu testes que le texte est au bon endroit (ce que fait le test "programmeur"). Tu n'as pas d'équivalence entre les 2 tests, l'équivalence aurait été si dans le test Cypress tu avais indiqué que n'importe quel élément peut avoir ce texte, et que le test Cypress avait testé la visibilité de l'élément (ton test UUV sera bon à refaire si jamais le bouton devient volontairement invisible, pas ton test Cypress, du travail en plus pas à faire avec le test Cypress donc plus cher).
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.
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 qui se balade parce que bon, au final c'est un programme qui va manger la chose donc avec des programmeurs (qui devront donc se taper à apprendre leur JSON et JS etc... Et un autre langage car UUV c'est joli mais sauf si ils ont mis une IA super costaud derrière il attend des phrases précises qu'il faut pas connaître en lisant mais qu'il faut connaître en écrivant).
Les cas 2 et 3 se font en Cypress aussi et sont hors sujet (plutôt sur la liste de tests à faire), comme si tu avais eu le sentiment inconscient de devoir remplir pour "vendre" UUV qui ne serait pas assez convainquant sans en rajouter, ça fait pour qui réfléchit un peu l'inverse de ce que tu veux faire (c'est un "red flag" classique).
Si les tests sont "compliqués" avec un langage "compliqué", ce n'est pas forcément par plaisir sadique mais qu'il y a bien un besoin plus compliqué qu'il ne parait à premier abord.
Si tu veux argumenter sur le sujet loin d'être aussi évident que affiché dans le journal et loin d'être nouveau, tu devrais commencer par éviter les hors sujet, et fournir des exemple Cypress vers UUV qui font exactement le même taf ou expliquer pourquoi tu changes le test (et pourquoi c'est bien).
# Tests différents (ou partiels)
Posté par Zenitram (site web personnel) . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 9.
Dans ton 1, tu proposes de changer un test "programmeur" par un test "utilisateur" mais tu oublies la moitié du test "programmeur", ton test "utilisateur" sera valide sur la PR intervertit les textes de 'app-title' et 'start-button', pas le test "programmeur".
tu écris :
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.
Yep, et ces testIds (euh... Perso c'était pas ajouté pour le fun, l'ID 'start-button' est utilisé ensuite pour raison X ou Y dans le code JS, par exemple le désactiver si un champs n'est pas rempli) ont une autre finalité dans le test, tu n'as pas montré dans ton test "utilisateur" comment tu testes que le texte est au bon endroit (ce que fait le test "programmeur"). Tu n'as pas d'équivalence entre les 2 tests, l'équivalence aurait été si dans le test Cypress tu avais indiqué que n'importe quel élément peut avoir ce texte, et que le test Cypress avait testé la visibilité de l'élément (ton test UUV sera bon à refaire si jamais le bouton devient volontairement invisible, pas ton test Cypress, du travail en plus pas à faire avec le test Cypress donc plus cher).
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.
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 qui se balade parce que bon, au final c'est un programme qui va manger la chose donc avec des programmeurs (qui devront donc se taper à apprendre leur JSON et JS etc... Et un autre langage car UUV c'est joli mais sauf si ils ont mis une IA super costaud derrière il attend des phrases précises qu'il faut pas connaître en lisant mais qu'il faut connaître en écrivant).
Les cas 2 et 3 se font en Cypress aussi et sont hors sujet (plutôt sur la liste de tests à faire), comme si tu avais eu le sentiment inconscient de devoir remplir pour "vendre" UUV qui ne serait pas assez convainquant sans en rajouter, ça fait pour qui réfléchit un peu l'inverse de ce que tu veux faire (c'est un "red flag" classique).
Si les tests sont "compliqués" avec un langage "compliqué", ce n'est pas forcément par plaisir sadique mais qu'il y a bien un besoin plus compliqué qu'il ne parait à premier abord.
Si tu veux argumenter sur le sujet loin d'être aussi évident que affiché dans le journal et loin d'être nouveau, tu devrais commencer par éviter les hors sujet, et fournir des exemple Cypress vers UUV qui font exactement le même taf ou expliquer pourquoi tu changes le test (et pourquoi c'est bien).