Donc, si ton bouton est renommé, ton test doit planter, parce que tes spécifications fonctionnelles ont changées. Donc il faut les retoucher.
Oui, tout à fait. Le problème, c’est de trouver quels tests il faut retoucher. Et quand t’as une suite de plusieurs milliers de tests, c’est pas forcément évident comme tâche. D’où l’intérêt d’être très précis dans tes sélecteurs. Y’a un autre aspect aussi, c’est de décrire précisément la semantique du test. Un test qui foire en disant "couldn’t find get started button", ca t’aide pas forcément à comprendre que c’est le bouton "login to get started" que tu cherches maintenant, alors que "button with id get-started has label login, expected get started", ca clarifie tout de suite les choses.
La spec c'est par exemple, je dois avoir un bouton nommé bouton dans le panier et je dois avoir un bouton nommé "bouton" dans le menu.
Ce genre de spec reconnaît implicitement le problème, sans permettre de le résoudre proprement. Ton example ici marche, mais c’est un exemple trivial. Une liste avec des doublons va te donner beaucoup de fil à retordre avec cette approche. D’ailleurs, les listes sont typiquement un enfer à gérer dans ces tests, surtout quand tu cherches un élément qui est en dessous du fold (lazy loading/reutilisation de vues).
C'est un fait, ce n'est pas propre à UUV, mais à toute technologie de test E2E à minima. Il faut bien configurer les solutions que l'on utilise y compris les timeouts. Très souvent on laisse la conf par défaut qui n'est pas du tout adapté à notre besoin. Je préfère répondre comme ça, parce quand je lis tes remarque sur cette partie, c'est comme si tu préconisais de ne pas faire de test E2E automatisé du tout :-D
Oula, non, pas du tout. On fait tourner plus de 4000 tests UI sur chaque pull requests. Et même ça, c’est très très très loin d’être assez, ils nous en faudrait probablement 30 à 40000 pour avoir une couverture décente. Et notre approche scale a ce niveau, ça prendrait 15 à 20 minutes pour 40k tests. Et on a très très peu de tests unitaires, je dirais dans les 300 (appli grand publique qui marche pas sans le backend, 99% de notre logique est une logique ux, la logique métier est gérée par le backend).
Je répondais au point de barmic qui disait que ce genre de tests ne sont pas écrits par des développeurs, et ne sont pas à l’intention des développeurs. Je suis passé par cette approche, et je n’y croit absolument pas. Les problèmes techniques ouverts par des tests UI sont beaucoup trop complexe pour laisser cette tâche à des non techniques. Même l’équipe qa n’est pas équipée pour les écrire. C’est un problème d’ingénierie très difficile, qui ne peut être résolu que par des ingénieurs en development.
Les tests automatisés, c'est avant tout automatiser ce qui est facilement automatisable et qui fait gagner du temps à être automatisé.
Pas super convaincu, pour être honnête. Ça reste un effort, et y’a pas grand chose de facilement automatisable sur un service non trivial, le gain est trop petit. Même si tu peux effectivement automatiser qq chose sur ta home page trivial, ça va durer combien de temps avant que les mecs produits rajoutent suffisamment de choses pour avoir un intérêt?
mais ce qui n'est pas top, c'est que certains projets veulent tout automatiser et ça altère la perception vis à vis de ces pratiques de test.
la encore, pas trop d’accord. Pas du tout même. Tu peux quasiment tout automatiser. La encore, j’ai un biais vers iOS, qui a beaucoup de choses littéralement impossible à tester. Genre les api background location qui passent des objets n’ayant pas de constructeurs publique. Si tu peux pas instantier le paramètre passé à ton core location delegate, forcément ça va moins bien marcher maintenant, comme dirais l’autre.
La soluce, c’est de gruger. Ton core location delegate trampoline vers ta méthode à toi, qui prend un objet que tu peux instantier. Et tu gruges dans ton test, en appelant cette fonction la directement. Il va effectivement te manquer un bout dans ton test, mais au moins tu peux garantir que tout ce qui vient après le point d’entrée fonctionne comme il faut.
Le gros problème, c’est de savoir gruger, sans trop gruger. C’est un art. Mais tellement différent de beaucoup d’autre solutions software, surtout quand on parle d’ux.
[^] # Re: Tests différents (ou partiels)
Posté par groumly . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 2.
Oui, tout à fait. Le problème, c’est de trouver quels tests il faut retoucher. Et quand t’as une suite de plusieurs milliers de tests, c’est pas forcément évident comme tâche. D’où l’intérêt d’être très précis dans tes sélecteurs. Y’a un autre aspect aussi, c’est de décrire précisément la semantique du test. Un test qui foire en disant "couldn’t find get started button", ca t’aide pas forcément à comprendre que c’est le bouton "login to get started" que tu cherches maintenant, alors que "button with id get-started has label login, expected get started", ca clarifie tout de suite les choses.
Ce genre de spec reconnaît implicitement le problème, sans permettre de le résoudre proprement. Ton example ici marche, mais c’est un exemple trivial. Une liste avec des doublons va te donner beaucoup de fil à retordre avec cette approche. D’ailleurs, les listes sont typiquement un enfer à gérer dans ces tests, surtout quand tu cherches un élément qui est en dessous du fold (lazy loading/reutilisation de vues).
Oula, non, pas du tout. On fait tourner plus de 4000 tests UI sur chaque pull requests. Et même ça, c’est très très très loin d’être assez, ils nous en faudrait probablement 30 à 40000 pour avoir une couverture décente. Et notre approche scale a ce niveau, ça prendrait 15 à 20 minutes pour 40k tests. Et on a très très peu de tests unitaires, je dirais dans les 300 (appli grand publique qui marche pas sans le backend, 99% de notre logique est une logique ux, la logique métier est gérée par le backend).
Je répondais au point de barmic qui disait que ce genre de tests ne sont pas écrits par des développeurs, et ne sont pas à l’intention des développeurs. Je suis passé par cette approche, et je n’y croit absolument pas. Les problèmes techniques ouverts par des tests UI sont beaucoup trop complexe pour laisser cette tâche à des non techniques. Même l’équipe qa n’est pas équipée pour les écrire. C’est un problème d’ingénierie très difficile, qui ne peut être résolu que par des ingénieurs en development.
Pas super convaincu, pour être honnête. Ça reste un effort, et y’a pas grand chose de facilement automatisable sur un service non trivial, le gain est trop petit. Même si tu peux effectivement automatiser qq chose sur ta home page trivial, ça va durer combien de temps avant que les mecs produits rajoutent suffisamment de choses pour avoir un intérêt?
la encore, pas trop d’accord. Pas du tout même. Tu peux quasiment tout automatiser. La encore, j’ai un biais vers iOS, qui a beaucoup de choses littéralement impossible à tester. Genre les api background location qui passent des objets n’ayant pas de constructeurs publique. Si tu peux pas instantier le paramètre passé à ton core location delegate, forcément ça va moins bien marcher maintenant, comme dirais l’autre.
La soluce, c’est de gruger. Ton core location delegate trampoline vers ta méthode à toi, qui prend un objet que tu peux instantier. Et tu gruges dans ton test, en appelant cette fonction la directement. Il va effectivement te manquer un bout dans ton test, mais au moins tu peux garantir que tout ce qui vient après le point d’entrée fonctionne comme il faut.
Le gros problème, c’est de savoir gruger, sans trop gruger. C’est un art. Mais tellement différent de beaucoup d’autre solutions software, surtout quand on parle d’ux.