TLDR
Convertissez vos tests Cypress, Playwright ou Selenium en cas de test Thunders avec un assistant de code, sans réécriture.
Introduction : le problème de la migration
Migrer depuis Cypress, Playwright ou Selenium implique généralement de tout réécrire de zéro. Des centaines de tests, des semaines de travail et une suite gelée pendant toute la migration. C'est souvent la seule raison pour laquelle les équipes ne franchissent jamais le pas.
Vous pouvez éviter la réécriture. Pointez un assistant de code (Claude, ChatGPT, Cursor, GitHub Copilot…) vers votre dépôt et laissez-le convertir vos tests en cas de test Thunders. L'assistant lit le code des tests existants, en comprend la structure et produit des étapes lisibles que vous pouvez exécuter immédiatement.
Ce guide déroule un exemple concret avec Claude connecté à GitHub pour importer un ensemble de tests Cypress. Nous allons récupérer les fichiers de test, analyser les blocs describe et it, traduire les commandes en étapes, puis créer des cas de test Thunders prêts à l'emploi. La même méthode fonctionne pour Playwright et Selenium : nous signalerons au fil du guide les ajustements propres à ces frameworks.
Guide étape par étape
1. Créer un projet dans Thunders et récupérer son ID
Rendez-vous dans votre organisation Thunders, créez un nouveau projet et copiez l'ID du projet. Vous en aurez besoin à l'étape 5.
2. Copier la variable APP url depuis Thunders
Ouvrez le menu Apps, cliquez sur votre application web puis copiez la variable APP url. C'est l'URL de base que nous ajouterons devant tout chemin relatif présent dans vos tests (par exemple, /login devient https://yourapp.com/login). Vous en aurez besoin à l'étape 4.
Rendez-vous dans Apps, cliquez sur votre application web puis copiez la variable APP url. Vous en aurez besoin à l'étape 5.

3. Connecter votre IA à GitHub et à Thunders
Ce flux repose sur deux serveurs MCP : GitHub (pour lire vos fichiers de test) et Thunders (pour créer les cas de test). Ajoutez les deux.
Dans Claude, ouvrez Paramètres → Connecteurs → Ajouter un connecteur personnalisé et ajoutez :
- GitHub : saisissez l'URL du serveur MCP GitHub. Un Personal Access Token (PAT) GitHub est nécessaire pour l'authentification.
- Thunders : saisissez l'URL de votre serveur MCP Thunders (
https://api.thunders.ai/v1/mcp) et authentifiez-vous avec votre compte Thunders. Plus de détails ici.
Une fois connectés, les deux connecteurs apparaissent dans vos outils disponibles.
Ce guide utilise Claude ; la même approche fonctionne avec toute IA compatible avec les connecteurs MCP.
4. Lire vos fichiers de test
Ouvrez une nouvelle session Claude, cliquez sur le bouton Ajouter du contenu (l'icône plus) et choisissez Ajouter depuis GitHub pour parcourir votre dépôt connecté. Accédez à votre dossier de tests (le plus souvent e2e/, cypress/ ou tests/) et sélectionnez tous les fichiers de test concernés. Cette étape est facultative, mais elle aide Claude à se caler d'emblée sur le bon dossier. Le prompt de l'étape 5 utilisera de toute façon le connecteur MCP GitHub pour lire et lister les fichiers : vous pouvez donc la sauter et simplement indiquer le chemin du dossier dans votre prompt.
5. Lancer le prompt d'import
Copiez et exécutez le prompt ci-dessous en remplaçant <PROJECT_ID> par l'ID de votre projet Thunders et <APP_URL> par votre variable app url. Si vous utilisez Playwright ou Selenium, remplacez également « Cypress commands » et « describe / it blocks » par les équivalents de votre framework, et adaptez le glob de fichiers de la première ligne (par exemple *.spec.js, *.test.ts).
Deux serveurs MCP sont disponibles : GitHub (pour lire mon dépôt) et Thunders (pour créer les cas de test).
Avec le MCP GitHub, liste tous les fichiers de test Cypress correspondant à *.spec.ts dans le dossier indiqué.
Pour chaque fichier :
1. Lis le contenu du fichier.
2. Analyse chaque suite/test (blocs describe / it).
3. Pour chaque cas de test `it` :
a. Traduis les commandes Cypress, dans l'ordre, en instructions d'étapes claires et lisibles
(une action par étape, par exemple « Cliquer sur le bouton Login », « Saisir 'user@test.com' dans le champ Email »,
« Vérifier que le titre de la page est 'Dashboard' »). Conserve les assertions sous forme d'étapes de vérification explicites.
b. Pour toute URL relative, ajoute la variable <APP_URL> exactement telle quelle
(par exemple « /tool/calculator » devient « <APP_URL>/tool/calculator »). Laisse les URL absolues inchangées.
c. Rédige un titre court et descriptif d'après ce que le test vérifie.
d. Appelle `create_test_case` avec ce titre comme `name` et le projectId <PROJECT_ID>.
Récupère l'id du cas de test renvoyé.
e. Appelle `generate_test_steps` avec l'id du cas de test renvoyé et, comme scénario,
les étapes lisibles ordonnées de l'étape (a). N'invente PAS d'étapes absentes du test source.
Traite les fichiers un par un. Après chaque fichier, indique brièvement les cas de test créés (titre + id)
avant de passer au suivant.
6. Vérifier et valider les cas de test importés
Ouvrez votre projet Thunders et passez en revue les cas de test générés. Points à contrôler :
- les descriptions d'étapes sont lisibles et exactes ;
- le préfixe
<APP_URL>est appliqué de façon cohérente à toutes les URL relatives ; - les titres des tests reflètent bien ce que chaque test vérifie.
Lancez d'abord un petit lot et corrigez les problèmes de structure avant d'importer le reste de votre suite.
Conseils pour les gros dépôts
Sur une suite de tests volumineuse, évitez de lancer le prompt d'import sur l'intégralité du dépôt d'un coup : la fenêtre de contexte de l'IA a ses limites, et mélanger des domaines de test sans rapport peut entraîner un nommage incohérent ou des étapes oubliées. Importez plutôt dossier par dossier ou fonctionnalité par fonctionnalité (par exemple e2e/auth/, puis e2e/checkout/, puis e2e/dashboard/). Pour chaque lot, exécutez le prompt avec le même ID de projet, vérifiez les cas de test générés avant de continuer et corrigez rapidement les éventuels problèmes de structure.
La suite
Une fois vos tests dans Thunders, vous pouvez aller plus loin : les rattacher à différents environnements, les exécuter au sein d'un pipeline ou inviter vos collègues à les enrichir et à les maintenir. L'import n'est qu'un point de départ : le reste de votre workflow QA peut se construire à partir de là.
.png)




.png)


