Les trois défaillances d'exécution que le test des applications web doit couvrir
L'état résiduel
Une fenêtre modale se ferme en laissant le défilement bloqué. Un filtre persiste là où il n'a plus aucun sens.
N'apparaît qu'à la deuxième interaction, si bien qu'une reproduction repartant de zéro ne le révèle jamais.
Le rendu avant les données
La page s'affiche, la requête aboutit, aucun nouveau rendu n'a lieu.
Généralement intermittent, ce qui explique qu'il survive à la relecture du code.
Le second utilisateur
Des hypothèses de propriété et de visibilité construites à partir de la propre session du développeur.
Fonctionne parfaitement pour tous ceux qui l'ont développé.
La vérification qui en détecte la plus grande partie
Effectuez l'action deux fois, avec deux utilisateurs différents, en rechargeant la page entre les deux. Ce seul schéma touche les trois catégories, et c'est précisément ce que les tests manuels sautent parce que la première tentative a fonctionné.
Sur quoi faire porter les assertions
Sur quelque chose qu'un rechargement confirmerait. Un message de succès ne prouve pas que quoi que ce soit a été enregistré. Allez relire la donnée.
Sur l'absence de ce qui ne devrait plus être là. Après une suppression, la ligne a disparu. Après une déconnexion, les données ne sont plus visibles.
Sur le comportement pour quelqu'un d'autre. Le deuxième compte ne peut pas voir les enregistrements du premier.
La place du développement local
Le travail sur une application web se fait sur localhost bien avant tout déploiement, et une vérification qui ne fonctionne que sur une URL publique arrive trop tard pour influencer ce que vous construisez. Le CLI peut établir un tunnel vers une application qui tourne sur votre propre machine pour les exécutions frontend : la vérification est donc disponible pendant que vous travaillez encore. Les détails se trouvent dans le dépôt du CLI.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Le tableau de bord couvre le même périmètre pour ceux qui ne veulent pas d'installation locale.
Le test des deux onglets
Il existe une vérification manuelle à faire avant chaque mise en production qui rapporte bien plus qu'elle ne coûte, et presque personne ne la fait : ouvrez l'application dans deux onglets.
Faites quelque chose dans le premier, puis regardez le second. La plupart des applications web se comportent mal d'une manière ou d'une autre dans cette situation, et la nature de ce dysfonctionnement est instructive. Une liste qui ne se met pas à jour est généralement sans gravité. Une action obsolète qui réussit et écrase des données plus récentes est un vrai bug. Une session qui déconnecte un onglet quand l'autre rafraîchit un jeton est un vrai bug. Une mise à jour optimiste qui ne se réconcilie jamais est un vrai bug.
Cela prend deux minutes, ne demande aucun outillage, et sollicite exactement la jointure où l'état du serveur, l'état du navigateur et l'attente de l'utilisateur divergent. Si vous ne retenez qu'une seule habitude de cette page, retenez celle-là.
Rendre la vérification continue
Les défaillances d'exécution sont précisément celles qui réapparaissent, parce que les conditions qui les produisent sont faciles à recréer par accident.
La GitHub App est un webhook que vous configurez dans le tableau de bord TestSprite. Elle écoute l'événement de déploiement que votre pipeline produit déjà, si bien que rien ne change dans votre dépôt.
GitHub Actions place l'étape à l'intérieur de votre propre workflow, configurée depuis le terminal.
Comment TestSprite sollicite l'application en cours d'exécution
TestSprite ouvre l'application déployée et l'utilise comme le ferait une personne, ce qui est le seul moyen de voir l'état résiduel, le rendu avant les données et le comportement pour un second utilisateur. Les cas de test sont décrits en langage courant et générés à partir de votre produit, et leurs assertions portent sur ce qu'un rechargement confirmerait plutôt que sur un message affiché par le client.
La vérification du second utilisateur est un cas de test à part entière plutôt qu'un exercice de configuration, ce qui compte parce que les hypothèses sur les permissions sont la défaillance la plus susceptible d'atteindre un client et la moins susceptible d'être remarquée par celui qui a développé la fonctionnalité.
Les vérifications continuent ensuite de s'exécuter à chaque changement, de sorte que les désaccords entre les trois états qui ont produit un bug une fois ne peuvent pas réapparaître discrètement une fois la branche fusionnée.
Pourquoi ces problèmes n'apparaissent-ils pas en revue de code ?
Parce qu'ils sont des propriétés d'une interaction entre l'état du serveur, l'état du navigateur et l'historique. Un diff n'en montre aucun.
Peut-on tester cela avec des tests unitaires ?
En partie, au prix de beaucoup de mocks, et ces mocks encodent les mêmes hypothèses que le code. C'est l'exécution réelle qui tranche.
Comment tester le second utilisateur de manière fiable ?
Gardez un second compte par environnement et exécutez le même parcours avec les deux. C'est la vérification la moins coûteuse et la plus rentable du test des applications web.
Et les navigateurs mobiles ?
Les différences de taille d'affichage font apparaître un ensemble distinct de problèmes de mise en page et d'interaction. Il vaut la peine de couvrir les parcours principaux à une taille mobile si vous avez du trafic mobile.
Quelle part de tout cela peut s'exécuter en local ?
Les exécutions frontend peuvent atteindre une application sur votre machine via un tunnel. Les cibles backend qui ne sont pas joignables nécessitent toujours un environnement exposé.
Faites-le deux fois, avec deux utilisateurs, en rechargeant la page.
Le test des applications web doit couvrir l'état résiduel, le rendu avant les données et le comportement pour un second utilisateur, autant de choses invisibles dans le code source. Vérifiez ce qu'un rechargement confirme, contrôlez l'absence de ce qui devrait avoir disparu, et exécutez le même parcours avec quelqu'un d'autre.