Vos tests vous appartiennent : ce que nous avons appris en exportant des tests Thunders vers Playwright

Pourquoi une plateforme de test a-t-elle besoin d'un export ? Éviter le vendor lock-in

Beaucoup d'entreprises doivent pouvoir continuer à exécuter leurs tests si elles cessent de travailler avec un fournisseur. Parfois, c'est une clause du contrat. Parfois, c'est une politique de gestion du risque fournisseur ou un audit. Dans tous les cas, « nos tests n'existent que dans une plateforme » est une réponse difficile à donner.

L'export permet une meilleure réponse. C'est un instantané ponctuel de vos cas de test, dans un format ouvert que n'importe quel ingénieur peut lire et exécuter. Ce n'est pas une synchronisation, ni un outil de migration. C'est la garantie que vous conservez le travail investi dans vos tests.

‍

Que contient l'export Playwright de Thunders ?

Vous recevez un dossier unique pour votre projet Thunders :

• Un fichier de test par cas de test. Chaque étape Thunders devient un test.step avec le même titre, si bien que le rapport Playwright se lit comme votre test Thunders.
• Vos instructions, conservées en commentaires. Au-dessus de chaque bloc de code, l'export garde l'étape en langage naturel que vous avez écrite dans Thunders. Quiconque ouvre le fichier voit ce que le code est censé faire.
• Des modules partagés pour les tests réutilisés. Un cas de test réutilisé par d'autres, comme une connexion, devient une seule fonction partagée, et non une copie dans chaque fichier.
• Un fichier d'environnement par environnement. Vous choisissez l'environnement à l'exécution. Les valeurs secrètes sont vides.
• Vos fichiers de test. Les fichiers utilisés par les étapes d'upload et les images de référence des vérifications visuelles sont fournis avec le projet.
• Un rapport d'export. Il commence par ce que vous devez configurer avant la première exécution, puis indique, pour chaque cas de test, combien d'étapes ont été exportées entièrement, partiellement ou sous forme de TODO.

‍

Qu'avons-nous obtenu sur de vrais tests ?

• 95 % des étapes exportées en code complet et exécutable : navigation, clics, saisie, listes déroulantes, appels API avec leurs vérifications, étapes JavaScript, etc.
• 3 % des étapes exportées partiellement : le code est là, mais il a besoin de quelque chose de votre part, comme une session enregistrée ou une image de référence.
• 2 % des étapes devenues des TODO : des commentaires clairs qui indiquent quoi écrire, avec votre instruction d'origine conservée au-dessus.

Le projet exporté s'est installé sans problème et a compilé sans aucune erreur. Puis nous l'avons exécuté.

‍

Qu'est-ce qui ne s'exporte pas vers Playwright, et pourquoi ?

C'est la partie la plus instructive de l'exercice. Toutes les étapes qui ne sont pas sorties en code complet avaient la même cause : dans Thunders, cette étape s'appuie sur de l'intelligence à l'exécution, et un script statique n'en a aucune.

‍

Les vérifications écrites en langage naturel

Dans Thunders, une vérification est une phrase, et Thunders l'évalue sur la vraie page, comme le ferait un testeur attentif :

• « Vérifie que les résultats de recherche sont triés par prix, du moins cher au plus cher. »
• « Vérifie que le message d'erreur explique à l'utilisateur comment corriger la date. »
• « Confirme que la photo du produit correspond au nom du produit. »
• « Vérifie que toute la page de paiement est en français, boutons compris. »
• « Vérifie que la date de livraison sur la confirmation est un jour ouvré postérieur à aujourd'hui. »

Chacune tient en une ligne dans Thunders. Dans Playwright, chacune est un petit programme : lire tous les prix et les comparer, analyser une date et vérifier le calendrier, ou appeler vous-même un modèle d'image ou de langage. L'export conserve votre phrase en commentaire, avec un TODO là où vous écrirez ce programme.

‍

Les sélecteurs auto-réparants

Thunders retrouve le bon élément même quand votre interface change. L'export, lui, ne peut que figer le sélecteur qui a fonctionné lors de la dernière exécution réussie. Beaucoup ressemblent à ceci :

/html[1]/body[1]/div[3]/input[1]

Ils fonctionnent aujourd'hui. Ils casseront le jour où un développeur ajoutera un bandeau au-dessus du formulaire. Dans Thunders, le même test continue de passer.

‍

Les données que Thunders génère

« Génère un nom de client aléatoire » produit une donnée nouvelle à chaque exécution Thunders. Quand votre étape demande un type de donnée courant (nom, e-mail, numéro de téléphone, nombre dans une plage, date, mot de passe ou identifiant), l'export écrit du code qui la génère comme Thunders, pour que chaque exécution ait des données neuves. Quand votre étape demande quelque chose de plus précis, comme une plaque d'immatriculation dans un format donné ou un nom qui doit commencer par une lettre donnée, Thunders comprend la demande, mais l'export ne le peut pas. Il rejoue la valeur de la dernière exécution, avec un TODO pour la remplacer par votre propre générateur.

‍

Les valeurs que Thunders lit sur la page

Thunders peut lire un total, un numéro de commande ou un code à l'écran et le réutiliser dans les étapes suivantes. Quand Thunders sait quel élément il a lu, l'export écrit du code qui lit ce même élément à l'exécution, pour que la valeur soit toujours à jour. Il ne copie jamais une valeur issue d'une exécution précédente, car elle pourrait contenir des données personnelles ou un jeton. Thunders va plus loin : il comprend une demande comme « garde seulement le nombre » ou « prends la deuxième ligne », et il transforme la valeur comme vous l'avez demandé. Dans l'export, cette dernière partie devient un TODO.

‍

Les comparaisons visuelles et de fichiers

Thunders compare les captures d'écran et les fichiers avec de l'IA, ce qui lui permet d'ignorer les différences sans importance. Playwright compare des pixels. La vérification visuelle s'exporte, mais vous devrez probablement ajuster son seuil. Une comparaison de fichiers devient un commentaire qui décrit la vérification d'origine.

‍

La stabilité et les relances

Thunders attend que la page soit stable et relance une action qui échoue momentanément. Le code exporté n'a pas cette logique : quand un élément n'est pas prêt, le test échoue.

‍

Le Mobile, l'Accessibilité et le Persona Testing

Le test mobile, les tests d'accessibilité et le Persona Testing sont des fonctionnalités de la plateforme. Ils s'exécutent avec vos étapes dans Thunders et n'existent pas dans un script Playwright.

‍

Le code exporté est-il plus rapide que Thunders ?

On pourrait s'attendre à ce qu'un simple script batte une plateforme qui réfléchit à chaque étape.

Sur les tests que les deux peuvent exécuter, ce n'est pas le cas. Dans nos mesures, une exécution CI complète a pris 24 secondes dans Thunders, contre 47 secondes pour le projet Playwright exporté, sur la même application et le même environnement. C'est presque deux fois plus rapide.

Trois éléments expliquent cet écart :

• Une attente plus intelligente. Un script attend selon des règles fixes : un délai, ou un élément qui devient visible. Thunders observe la page elle-même et passe à la suite dès qu'elle est stable. Il n'attend donc pas plus que nécessaire, et il n'agit pas trop tôt sur une page encore en chargement.
• Des décisions prises à plus bas niveau. Thunders dialogue directement avec le navigateur. Il décide comment cliquer, saisir et attendre en fonction de ce que la page affiche réellement, au lieu de passer par une couche d'actions générique à chaque étape.
• Une infrastructure conçue pour le test. Thunders exécute vos tests sur des navigateurs prêts avant le lancement, proches de votre application, et en parallèle. Un projet Playwright s'exécute là où vous le placez : souvent une seule machine de CI qui démarre un navigateur à chaque exécution. Découvrez comment Thunders exécute les tests à grande échelle avec Jev.

Le projet exporté reste rapide et léger, et vous pouvez l'optimiser. Mais égaler ces trois points demande un travail d'ingénierie que votre équipe devra porter.

‍

Alors, faut-il exécuter vos tests dans Thunders ou dans Playwright ?

Les deux fonctionnent, mais ils ne font pas le même travail.

L'export Playwright est un instantané. Il capture la logique de vos tests le jour de l'export, et à partir de ce jour, c'est votre équipe qui la maintient. Chaque changement d'interface est un sélecteur à corriger à la main. Chaque vérification en langage naturel est du code à écrire. Chaque valeur générée est un générateur à construire.

Thunders est une suite de tests vivante. Il répare les sélecteurs quand votre interface change, évalue les assertions en langage naturel sur la vraie page, génère des données neuves à chaque exécution, tranche les conditions comme le ferait une personne, et exécute vos tests sur le web et le mobile. Ce sont les 5 % qu'aucun export ne peut emporter, et d'après notre expérience, c'est là que part l'essentiel du temps de maintenance d'une suite de tests.

L'export répond donc « oui » sans hésiter à la question « pouvons-nous partir ? ». Il montre aussi, ligne par ligne, ce que vous auriez à prendre en charge si vous le faisiez.

‍

Comment obtenir un export ?

Clients cloud : demandez à votre contact Thunders. Thunders prépare l'export et vous envoie un lien de téléchargement sécurisé qui expire au bout de 7 jours.

Clients auto-hébergés : vous lancez l'export vous-même sur votre instance, avec une clé API de votre organisation.

Dans les deux cas, ouvrez d'abord le rapport d'export. Sa section « Before you run » liste les secrets à renseigner et les sessions à enregistrer. Lancez ensuite :

npm ci
npx playwright install chromium
npx playwright test

‍

La place de Thunders dans votre stratégie de test

Thunders permet à chacun de décrire un test end-to-end en langage naturel, l'exécute dans un vrai navigateur ou sur un vrai appareil, et le maintient fonctionnel quand votre produit évolue. L'export Playwright en est la garantie : vos tests vous appartiennent toujours, dans un format ouvert, dès que vous en avez besoin.

Créez un compte Thunders gratuit ou demandez une démo pour voir les deux sur votre propre application.

‍