C’est un sujet qui me tient à cœur, et dans lequel j’ai passé beaucoup de temps (facile 20% des 12 dernières années). J’ai un peut tout tenté, pour être honnête. Du cucumber et dérivé, du bdd, du pure black box testing, de l’officiel Apple, du à l’arrache, de l’hybride. Du page object model, de l’unitaire pur. Sur iOS spécifiquement, qui est honnêtement un véritable cauchemar à tester de façon fiable.
J’ai même donné un talk y’a pas longtemps la dessus, c’est dire si j’assure (sarcasme, évidemment).
Donc c'est pas le développeur qui les écris ou en tout cas pas celui qui écris le code et il ne sont pas à destination des développeurs.
Ton kilométrage va varier, en fonction de beaucoup de chose, mais en gros, mon opinion c’est absolument pas, pas pour tester une UX utilisateur comme OP le fait dans son naljour.
Pour nuancer le propos, si tu fait ça, tu vas vaguement tester en surface, ça va te coûter un temps fou, avec beaucoup de false positive et false négative, et tu vas dépenser beaucoup d’énergie pour au final très peu. Avec en cadeau bonux une fausse impression de sécurité qui va te retomber sur le coin de la gueule un jour.
Ce que j’ai apprit sur l’automated UI tests (désolé pour l’anglicisme, je cause pas francais professionellement), c’est que c’est un problème super couillu ‘achement dur. Un truc de vrai gars/meuf qui en veut. T’as de l’asynchronicite de partout, 99% des frameworks sont beaucoup trop lent pour espérer avoir une quelconque couverture, le bon vieux problème des mocks, mais puissance 10 parce que tu testes en blackbox, la combinatoire explose très vite sur le moindre service même simple. Beaucoup d’architecture, parce que tout doit être mockable, et contrôlable. Beaucoup de precondition à vérifier, énormément de mock data à injecter, et énormément de sucre syntaxique, parce qu’un flow de base, c’est vite 100-200 test pour une couverture juste passable. Et du coup, énormément de maintenance. Rien que définir ce que chaque test est censé tester, comment les découper et les organiser devient très très vite un problème. Ça prend beaucoup de domaines pas forcément simple, et les combine pour faire un plus gros problème. <insert joining forces meme>
L’exemple numéro 1 est rigolo, il est en plein dedans. Ce test va peter la seconde ou le label va changer. Ou peut être pas, si par malheur t’as un autre bouton nommé get started (que t’as oublié, ou qui est correct, les 2 sont funs, mais de façons différente). Ou si tu fais un a/b test. C’est pas pour rien qu’on test généralement par id. Le test c’est pas de savoir si y’a un bouton qui, par hasard, s’appelle get started, mais de vérifier si ce bouton s’appelle get started. Et que ce bouton est hidden quand t’es connecté, mais en fait non, tout le bloc auquel ce bouton appartient, etc. C’est un example basique de chez basique, qui effleure à peine la moindre logique métier, et c’est déjà pas glorieux.
l’example numero 2 aussi est marrant. Ça marche, peut être. T’as deux options en fait. Une animation est ajoutée, et paf l’asynchronicite, t’as un test de shrodinger. Des fois il passe, des fois il passe pas. Option 2, le framework de test attend. Longtemps. Et la ça passe. Jusqu’à ce que le test capture un vrai problème, tous les test sur cette feature petent, et paf, ton pipeline se prend 15 minutes dans la gueule. Multiplies ca par le nombre d’ingénieurs qui bosse sur le projet en parallèle, et tu te rends compte que ton pipeline passe son temps stallé à attendre que des test fail (je vous l’ai dit, je cause pas la France professionnellement. Appelles moi jcvd si tu veux, ça m’en touche une sans faire bouger l’autre).
Une equipe qa qui roule bien, c’est des gens un peu technique qui arrive à groker pas mal d’outils, lisent du code pas trop aride sans trop de problème, mais galèrent à écrire autre chose que de l’impératif simple. Et surtout, surtout, des sociopathes qui sont obsédés à l’idée de casser leurs jouets (le site web/l’appli), dotés d’un sens de l’observation et une attention au détail redoutables (ok, j’exagère sur le côté sociopathe). C’est une mentalité particulière, et surtout c’est diamétralement opposé à la mentalité classique de l’ingénieur qui essaye de construire quelque chose. Tout ça pour dire, tu vas avoir beaucoup de mal à trouver quelqu’un qui a à la fois la technique pour résoudre des problèmes d’ingénierie pas piqués des hannetons, et qui arrive aussi a penser comme il faut pour tout peter.
Les autres membres de l’équipe, t’oublies. Les mecs produits ne comprennent pas la moitié de ce message, les designers, bah c’est des designers, le project manager sue à grosses gouttes dès que tu le sort d’excel, le manager est trop occupé à se la peter en meeting pour s’approcher d’un compilateur.
Bref, comment tu resoud ça? C’est pas facile. Mais tu prends des ingénieurs doués, tu les motives en leur montrant le côté couillu du problème (carrotte), tu leur prends bien la tête quand y’a une régression (baton), et tu les félicite quand la CI fail un build sur une régression (deuxième 🥕). Tu leur fait écrire la couverture de base quand ils écrivent la feature en premier lieu, ça sera super léger au début, et ensuite ils vont apprendre et s’améliorer. Ensuite t’envoie ça à la qa manuelle. Et chaque bug filé repart au dev, qui ajoute un test d’abord, et ensuite corrige le bug (ça par contre, c’est une bataille en pente qui monte, comme ils disent outre quebin). Ah, et évidemment, en amont, t’as un ou deux gars qui est responsable de mettre en place toute l’infra. Le coeur du harnais de test, la ci, la DevX, les patterns pour à peu près tout, la doc, etc.
bref, les tests automatisés, c’est fait par des développeurs pour des développeurs, et ca sert à 100% à détecter les régressions, certainement pas à valider la feature en premier lieu. La qa c’est manuel, fait par des des profils précis, et c’est 100% pour ta validation initiale.
[^] # 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é à 10.
C’est un sujet qui me tient à cœur, et dans lequel j’ai passé beaucoup de temps (facile 20% des 12 dernières années). J’ai un peut tout tenté, pour être honnête. Du cucumber et dérivé, du bdd, du pure black box testing, de l’officiel Apple, du à l’arrache, de l’hybride. Du page object model, de l’unitaire pur. Sur iOS spécifiquement, qui est honnêtement un véritable cauchemar à tester de façon fiable.
J’ai même donné un talk y’a pas longtemps la dessus, c’est dire si j’assure (sarcasme, évidemment).
Ton kilométrage va varier, en fonction de beaucoup de chose, mais en gros, mon opinion c’est absolument pas, pas pour tester une UX utilisateur comme OP le fait dans son naljour.
Pour nuancer le propos, si tu fait ça, tu vas vaguement tester en surface, ça va te coûter un temps fou, avec beaucoup de false positive et false négative, et tu vas dépenser beaucoup d’énergie pour au final très peu. Avec en cadeau bonux une fausse impression de sécurité qui va te retomber sur le coin de la gueule un jour.
Ce que j’ai apprit sur l’automated UI tests (désolé pour l’anglicisme, je cause pas francais professionellement), c’est que c’est un problème super couillu ‘achement dur. Un truc de vrai gars/meuf qui en veut. T’as de l’asynchronicite de partout, 99% des frameworks sont beaucoup trop lent pour espérer avoir une quelconque couverture, le bon vieux problème des mocks, mais puissance 10 parce que tu testes en blackbox, la combinatoire explose très vite sur le moindre service même simple. Beaucoup d’architecture, parce que tout doit être mockable, et contrôlable. Beaucoup de precondition à vérifier, énormément de mock data à injecter, et énormément de sucre syntaxique, parce qu’un flow de base, c’est vite 100-200 test pour une couverture juste passable. Et du coup, énormément de maintenance. Rien que définir ce que chaque test est censé tester, comment les découper et les organiser devient très très vite un problème. Ça prend beaucoup de domaines pas forcément simple, et les combine pour faire un plus gros problème. <insert joining forces meme>
L’exemple numéro 1 est rigolo, il est en plein dedans. Ce test va peter la seconde ou le label va changer. Ou peut être pas, si par malheur t’as un autre bouton nommé get started (que t’as oublié, ou qui est correct, les 2 sont funs, mais de façons différente). Ou si tu fais un a/b test. C’est pas pour rien qu’on test généralement par id. Le test c’est pas de savoir si y’a un bouton qui, par hasard, s’appelle get started, mais de vérifier si ce bouton s’appelle get started. Et que ce bouton est hidden quand t’es connecté, mais en fait non, tout le bloc auquel ce bouton appartient, etc. C’est un example basique de chez basique, qui effleure à peine la moindre logique métier, et c’est déjà pas glorieux.
l’example numero 2 aussi est marrant. Ça marche, peut être. T’as deux options en fait. Une animation est ajoutée, et paf l’asynchronicite, t’as un test de shrodinger. Des fois il passe, des fois il passe pas. Option 2, le framework de test attend. Longtemps. Et la ça passe. Jusqu’à ce que le test capture un vrai problème, tous les test sur cette feature petent, et paf, ton pipeline se prend 15 minutes dans la gueule. Multiplies ca par le nombre d’ingénieurs qui bosse sur le projet en parallèle, et tu te rends compte que ton pipeline passe son temps stallé à attendre que des test fail (je vous l’ai dit, je cause pas la France professionnellement. Appelles moi jcvd si tu veux, ça m’en touche une sans faire bouger l’autre).
Une equipe qa qui roule bien, c’est des gens un peu technique qui arrive à groker pas mal d’outils, lisent du code pas trop aride sans trop de problème, mais galèrent à écrire autre chose que de l’impératif simple. Et surtout, surtout, des sociopathes qui sont obsédés à l’idée de casser leurs jouets (le site web/l’appli), dotés d’un sens de l’observation et une attention au détail redoutables (ok, j’exagère sur le côté sociopathe). C’est une mentalité particulière, et surtout c’est diamétralement opposé à la mentalité classique de l’ingénieur qui essaye de construire quelque chose. Tout ça pour dire, tu vas avoir beaucoup de mal à trouver quelqu’un qui a à la fois la technique pour résoudre des problèmes d’ingénierie pas piqués des hannetons, et qui arrive aussi a penser comme il faut pour tout peter.
Les autres membres de l’équipe, t’oublies. Les mecs produits ne comprennent pas la moitié de ce message, les designers, bah c’est des designers, le project manager sue à grosses gouttes dès que tu le sort d’excel, le manager est trop occupé à se la peter en meeting pour s’approcher d’un compilateur.
Bref, comment tu resoud ça? C’est pas facile. Mais tu prends des ingénieurs doués, tu les motives en leur montrant le côté couillu du problème (carrotte), tu leur prends bien la tête quand y’a une régression (baton), et tu les félicite quand la CI fail un build sur une régression (deuxième 🥕). Tu leur fait écrire la couverture de base quand ils écrivent la feature en premier lieu, ça sera super léger au début, et ensuite ils vont apprendre et s’améliorer. Ensuite t’envoie ça à la qa manuelle. Et chaque bug filé repart au dev, qui ajoute un test d’abord, et ensuite corrige le bug (ça par contre, c’est une bataille en pente qui monte, comme ils disent outre quebin). Ah, et évidemment, en amont, t’as un ou deux gars qui est responsable de mettre en place toute l’infra. Le coeur du harnais de test, la ci, la DevX, les patterns pour à peu près tout, la doc, etc.
bref, les tests automatisés, c’est fait par des développeurs pour des développeurs, et ca sert à 100% à détecter les régressions, certainement pas à valider la feature en premier lieu. La qa c’est manuel, fait par des des profils précis, et c’est 100% pour ta validation initiale.