Alternative à Cypress : où partir et comment migrer tes tests

Pourquoi partir sur Playwright. Il règle d'un coup les trois reproches faits à Cypress. Il pilote Chromium, Firefox et WebKit sur Windows, Linux et macOS, il gère plusieurs onglets et plusieurs domaines dans le même test, et il lance tes tests en parallèle par défaut. Le découpage d'une suite sur plusieurs machines de CI (--shard=1/4, --shard=2/4…) est gratuit, et npx playwright merge-reports fusionne les rapports en une seule page HTML. Ce que Cypress Cloud fait payer, Playwright le fait dans le paquet open source (licence Apache-2.0, environ 99 000 étoiles sur GitHub).

Pour qui. Les équipes de développeurs en TypeScript, mais aussi en Python, Java ou .NET, qui veulent une seule base de tests pour tous les navigateurs.

Pour qui ce n'est pas fait. Une équipe sans développeur, ou une équipe qui tient avant tout au lanceur interactif de Cypress : le mode UI de Playwright s'en approche, mais l'expérience n'est pas la même.

Sa limite. Le test tourne dans Node.js, hors du navigateur : tu écris des await partout, et les attentes ne se gèrent pas tout à fait pareil. Les anciens paquets expérimentaux de tests de composants (React, Vue) ont été retirés : si tu fais beaucoup de tests de composants avec Cypress, lis le guide de Playwright avant de partir. Et le découpage ne répartit que des tests qui peuvent tourner en parallèle : des tests qui partagent un même compte de démo devront être séparés.

Comment migrer. Il n'existe pas d'outil officiel de conversion. Des convertisseurs communautaires font le gros du travail et marquent ce qu'ils ne savent pas traduire (une équipe a vu ses fonctions non converties préfixées FIXME_). Les correspondances de base : cy.get() devient page.locator(), cy.intercept() devient page.route(), cy.session() devient un état de connexion sauvegardé (storageState). Astuce : connecte-toi une seule fois dans un fichier de préparation global, au lieu de te reconnecter à chaque test comme beaucoup de suites Cypress le font. C'est souvent le premier gain de temps.

Pourquoi partir sur WebdriverIO. C'est l'alternative JavaScript qui va le plus loin hors du navigateur. Il s'appuie sur les standards WebDriver et WebDriver BiDi, pilote Chrome, Firefox, Safari et Edge, et teste aussi des applis iOS, Android et Flutter, natives ou hybrides. Ses tests de composants tournent dans un vrai navigateur, avec Testing Library pour React, Preact, Svelte ou Vue. Le projet est open source (licence MIT) et annonce que toutes ses fonctions sont gratuites.

Pour qui. Les équipes qui ont un site et une appli mobile, et qui veulent une seule façon d'écrire leurs tests.

Pour qui ce n'est pas fait. Une petite équipe qui ne teste qu'une appli web : la configuration est plus lourde que celle de Playwright, avec plus de choix à faire (lanceur de tests, services, rapports).

Sa limite. Le mobile natif demande d'installer et de faire tourner l'environnement mobile à côté (émulateurs, appareils réels ou ferme d'appareils dans le cloud). Le code est gratuit, l'infrastructure ne l'est pas.

Comment migrer. Le passage depuis Cypress est assez naturel : même langage, même logique de sélecteurs, assertions de style expect. Commence par l'assistant de configuration (npm init wdio@latest), garde Mocha, le choix par défaut, pour retrouver les blocs describe et it que tu connais, puis migre fichier par fichier.

Pourquoi partir sur Selenium. C'est l'outil historique, et il reste le seul à couvrir six langages : Java, Python, C#, Ruby, JavaScript et Kotlin. Si ton équipe QA écrit en Java avec JUnit, ou tes développeurs en Python avec pytest, Selenium leur évite d'apprendre un nouveau langage. Selenium Grid répartit les tests sur plusieurs machines et navigateurs depuis un point central. Licence Apache-2.0.

Pour qui. Les grandes équipes QA multi-langage, les entreprises qui ont déjà une grille Selenium ou un contrat avec une ferme de navigateurs.

Pour qui ce n'est pas fait. Une équipe front-end habituée au confort de Cypress : Selenium n'attend pas tout seul qu'un élément soit prêt, tu gères les attentes toi-même.

Sa limite. Le plus de code à écrire pour le même test, et des tests instables si les attentes sont mal posées. La grille, il faut l'héberger et la maintenir, ou payer un service.

Comment migrer. Réécriture complète, puisque le langage change souvent. Profites-en pour poser un modèle par page (Page Object Model) dès le début, et des attentes explicites. Notre page quitter Selenium détaille l'autre sens du chemin, utile pour voir ce qui fait partir les équipes.

Pourquoi partir sur TestCafe. Il s'installe avec un seul paquet npm (npm i -g testcafe) et lance les navigateurs courants sans autre réglage : Chrome, Firefox, Safari, Edge et Opera. Il sait ouvrir plusieurs fenêtres et passer de l'une à l'autre dans un test, ce que Cypress ne fait pas sans plugin (seulement sur Chrome et Firefox en local, pas sur les navigateurs distants). Les tests s'écrivent en JavaScript ou TypeScript, et le projet de DevExpress est open source (licence MIT).

Pour qui. Une petite équipe JavaScript qui veut sortir de Cypress vite, sans apprendre un outil plus vaste.

Pour qui ce n'est pas fait. Une équipe qui veut l'outil sur lequel la communauté investit le plus : TestCafe compte environ 9 900 étoiles sur GitHub, dix fois moins que Playwright, et on trouve moins de réponses toutes faites.

Sa limite. Un écosystème plus petit (plugins, exemples, offres d'emploi), et pas de mobile natif.

Comment migrer. La syntaxe change (t.click() au lieu de cy.get().click(), sélecteurs via Selector()), mais la logique reste la même. Migre d'abord tes cinq parcours les plus critiques pour juger l'outil sur ton application avant de convertir le reste.

Pourquoi partir sur Katalon. Katalon couvre le web, le mobile, les API et le bureau dans un même outil, avec un enregistreur de parcours pour les testeurs qui ne codent pas et un mode script pour ceux qui codent. Pour une équipe QA mixte, c'est un seul outil au lieu de trois.

Pour qui. Les équipes QA qui mélangent testeurs fonctionnels et automaticiens, et qui veulent rapports et gestion des tests au même endroit.

Pour qui ce n'est pas fait. Une équipe de développeurs qui veut ses tests dans le dépôt, relus en revue de code comme le reste.

Sa limite. Le plan gratuit n'exécute qu'en local, jusqu'à 40 suites, sans parallèle ni CI. L'exécution en CI demande Professional, à 1 800 $ par siège et par an, soit 150 $ par mois et par personne. Pour une équipe de cinq, compte 9 000 $ par an.

Comment migrer. Pas d'import de tests Cypress : tu recrées tes parcours avec l'enregistreur ou en script. Profite de l'essai de 30 jours pour reconstruire tes dix parcours critiques et voir si l'équipe adopte l'outil.

Pourquoi partir sur Ghost Inspector. Tu enregistres un parcours dans ton navigateur (inscription, ajout au panier, paiement), et Ghost Inspector le rejoue dans son cloud, à heure fixe ou à chaque mise en production. Pas de CI à monter, pas de navigateur à installer. Pour une équipe produit ou marketing qui veut savoir avant ses clients qu'un formulaire est cassé, c'est le chemin le plus court.

Pour qui. Les équipes sans développeur dédié aux tests, les agences qui surveillent les sites de leurs clients.

Pour qui ce n'est pas fait. Une équipe qui veut des tests versionnés avec le code et des cas complexes (données générées, appels d'API) : l'enregistreur atteint vite ses limites.

Sa limite. Le prix. Starter coûte 125 $ par mois, ou 109 $ par mois à l'année (1 308 $ par an), pour 10 000 exécutions par mois. Growth monte à 249 $ (225 $ à l'année) pour 30 000. Une exécution, c'est un test lancé une fois : 30 tests lancés dix fois par jour consomment 9 000 exécutions par mois.

Comment migrer. Pas d'import Cypress. Réenregistre tes parcours critiques un par un pendant l'essai de 14 jours, sans carte bancaire, qui donne accès à toutes les fonctions du plan Scale.

Pourquoi partir sur BugBug. Même principe que Ghost Inspector (on enregistre, l'outil rejoue), avec un plan gratuit sans limite d'exécutions en local. Pour une petite équipe qui veut couvrir ses parcours clés sans budget, c'est un bon point de départ.

Pour qui. Les startups et petites équipes produit, les fondateurs qui veulent un filet de sécurité avant chaque mise en ligne.

Pour qui ce n'est pas fait. Une suite de plusieurs centaines de tests, ou des tests multi-navigateurs poussés.

Sa limite. Le gratuit ne tourne qu'en local, pour un utilisateur, un projet, 15 tests et 4 suites, avec 7 jours d'historique. L'exécution dans le cloud commence avec Core, à 99 $ par mois à l'année, puis Pro à 189 $ par mois à l'année. Chaque exécution parallèle en plus coûte 80 $ par mois.

Comment migrer. Réenregistre tes 15 parcours les plus importants dans le plan gratuit. Si l'équipe s'en sert vraiment au bout d'un mois, passe à Core pour les lancer dans le cloud à chaque mise en production.

Pourquoi partir sur QA Wolf. Ce n'est pas un framework, c'est un service : leur équipe écrit tes tests, les fait tourner, répare ceux qui cassent et ouvre les tickets de bugs dans Linear ou Jira. Les tests sont écrits en Playwright standard et restent exportables : si tu pars, tu gardes le code.

Pour qui. Une équipe produit qui n'a pas de QA et ne veut pas en recruter, ou dont la suite Cypress est à l'abandon.

Pour qui ce n'est pas fait. Une équipe qui veut garder la main sur chaque test, ou un budget serré : le service se paie à chaque lancement.

Sa limite. Le coût monte avec la fréquence. QA Wolf facture 1 $ par exécution de test web (Chrome, Firefox, WebKit) et 2 $ en mobile ou bureau, avec jusqu'à 5 minutes par test et 3 tentatives incluses. Leur propre exemple : 50 tests web lancés une fois par jour ouvré, soit 260 jours, coûtent 13 000 $ par an, environ 1 083 $ par mois. Lance-les à chaque modification de code et la note grimpe d'autant.

Comment migrer. Donne-leur l'accès à ton application et la liste de tes parcours critiques. Ta suite Cypress sert de cahier des charges : chaque test est un parcours à couvrir. Garde-la en route tant que leur couverture n'a pas rattrapé la tienne.

Pourquoi partir sur mabl. mabl couvre dans un même outil les tests d'interface web et mobile, les API, la performance et l'accessibilité, avec des tests que des agents IA tiennent à jour quand l'interface change (l'éditeur parle d'auto-réparation). Les exécutions en local sont gratuites, celles du cloud consomment des crédits.

Pour qui. Les entreprises qui veulent un outil de test unique pour plusieurs équipes, avec un interlocuteur commercial.

Pour qui ce n'est pas fait. Une startup qui veut connaître son prix avant de parler à quelqu'un.

Sa limite. Aucun prix publié : tout passe par un devis. L'offre de départ inclut 500 crédits par mois pour les exécutions dans le cloud, partagés entre tous les types de tests. Demande combien de crédits consomme un test web, sinon tu ne pourras pas comparer avec Cypress Cloud.

Comment migrer. Recrée tes parcours pendant l'essai gratuit de 14 jours, en commençant par ceux qui cassent le plus souvent chez Cypress : c'est là que l'auto-réparation se juge.