TLDR
- Du déclenchement au résultat, Thunders a terminé les 50 tests en 64 secondes. Selenium a mis 106 secondes, Cypress 178 secondes et Playwright 196 secondes.
- Thunders est donc 40 % plus rapide que Selenium, 64 % plus rapide que Cypress et 67 % plus rapide que Playwright sur le chiffre que les développeurs attendent vraiment.
- Thunders a aussi été le plus rapide sur l’exécution seule: 64 secondes, contre 84 secondes pour Selenium, 152 secondes pour Cypress et 156 secondes pour Playwright.
- Les frameworks scriptés ont passé 22 à 40 secondes en préparation avant et autour de leurs tests, et ont consommé 2 à 4 minutes GitHub Actions facturables par exécution. Thunders n’a passé aucun temps hors des tests.
- L’écart vient de l’infrastructure. Un runner GitHub standard dispose de 2 vCPU pour toute l’exécution. Thunders exécute chaque test sur une flotte de navigateurs distribuée, conçue et optimisée uniquement pour les tests web.
Tous les développeurs connaissent cette attente. Vous poussez une modification, le pipeline démarre, et vous regardez une barre de progression. Une partie de ce temps va aux tests. Le reste part dans un travail qui ne teste rien: une machine démarre, le dépôt se télécharge, les dépendances s’installent, le code se compile, un navigateur s’installe.
Nous voulions mettre un chiffre sur cette attente. Nous avons donc pris 50 tests end-to-end et les avons exécutés de quatre façons: en scripts Playwright, Selenium et Cypress dans GitHub Actions, et en tests Thunders dans Thunders, une plateforme de test par l’IA pour les tests end-to-end. Puis nous avons mesuré deux choses: le temps d’exécution des tests, et la durée de l’exécution complète, du déclenchement au résultat.
Cet article présente les résultats, montre où passe le temps et explique pourquoi Thunders rend le résultat le plus rapidement.
Ce que nous avons mesuré
Nous avons écrit quatre fois les mêmes 50 tests end-to-end:
- Playwright, Selenium et Cypress: des scripts stockés dans un dépôt GitHub, exécutés par GitHub Actions.
- Thunders: des tests rédigés en langage naturel dans la plateforme Thunders, exécutés par Thunders.
Pour chacun, nous avons relevé deux chiffres:
- Temps d’exécution: le temps que prennent les tests, une fois que tout est prêt.
- Exécution CI complète: le temps entre le déclenchement et le résultat. C’est le chiffre qu’un développeur attend après un push.
Les conditions étaient les mêmes pour les quatre:
- Application testée: l’application web Thunders elle-même.
- Déclencheur: une CI de pull request pour Playwright, Selenium et Cypress. Thunders a tourné avec son planificateur intégré, il n’a donc besoin d’aucun job CI.
- Exécution parallèle: 10 tests à la fois sur chaque framework. Sur Thunders, 10 exécutions parallèles sont disponibles avec l’offre Enterprise, dont la parallélisation est configurable (voir les tarifs).
- Frameworks scriptés: un runner Linux standard hébergé par GitHub, avec 2 vCPU, les réglages et les caches standard.
- Chiffres: chaque chiffre est la médiane de plusieurs exécutions.
Les résultats
| Framework | Temps d’exécution | Exécution CI complète (runner 2 cœurs) | Temps hors des tests |
|---|---|---|---|
| Playwright | 156,1 s | 196 s | 40 s |
| Selenium | 84,2 s | 106 s | 22 s |
| Cypress | 152,0 s | 178 s | 26 s |
| Thunders | 64 s | 64 s** | 0 s |
** Thunders a tourné avec son planificateur intégré, pas dans un job CI. Il n’y a aucun runner CI à démarrer: l’exécution complète est donc égale au temps d’exécution, et elle ne consomme aucune minute GitHub Actions.
Thunders affiche l’exécution complète la plus courte
Du déclenchement au résultat, en secondes · 50 tests end-to-end, 10 à la fois · Frameworks scriptés sur un runner GitHub à 2 cœurs · Plus bas, c’est mieux
Thunders
Playwright
Selenium
CypressLe « temps hors des tests » correspond à l’exécution CI complète moins le temps d’exécution. GitHub facture chaque job à la minute entière: une exécution de 106 secondes coûte donc 2 minutes. Thunders tourne sur sa propre infrastructure: son exécution démarre sur un navigateur déjà prêt et ne consomme aucune minute de runner GitHub.
Sur l’exécution complète:
- Thunders est 40 % plus rapide que Selenium (64 s contre 106 s)
- Thunders est 64 % plus rapide que Cypress (64 s contre 178 s)
- Thunders est 67 % plus rapide que Playwright (64 s contre 196 s), soit environ 3 fois plus rapide
Où passe le temps
Une exécution CI comporte deux parties: la préparation et l’exécution.
Exécution + temps hors des tests
Secondes · Chaque barre correspond à l’exécution complète
ThundersPlaywrightSeleniumCypressLa préparation. Avant le premier test, un pipeline scripté passe 22 à 40 secondes à se préparer: démarrer le runner, récupérer le code, restaurer les dépendances, installer les navigateurs, compiler le projet. Ce coût revient à chaque pipeline, à chaque pull request, plusieurs fois par jour. Thunders ne passe aucun temps hors des tests: il n’y a ni runner à démarrer, ni rien à installer ou à compiler.
L’exécution. C’est ici que l’infrastructure fait la différence. Sur GitHub Actions, tous les navigateurs d’une exécution se partagent un runner standard de 2 vCPU. Chaque navigateur a besoin de CPU pour afficher la page et exécuter ses scripts: les navigateurs s’attendent donc les uns les autres, et chaque test ralentit. Thunders répartit les tests sur une flotte de navigateurs distribuée: un test n’entre jamais en concurrence avec les autres pour les mêmes 2 cœurs.
Playwright a le plus souffert du petit runner. Nous y voyons deux raisons probables. Ses workers semblaient se partager les 2 cœurs moins bien que ceux de Selenium. Il capturait aussi des preuves plus riches pour chaque test, et cette capture consomme du CPU ; sur une machine à 2 cœurs, ce coût peut ralentir tous les autres tests de l’exécution. Les tests Thunders sont rédigés en langage naturel et continuent de fonctionner quand l’interface change, et ils ont malgré tout exécuté les 50 tests en 64 secondes: 24 % plus vite que Selenium (84 s), et plus de deux fois plus vite que Cypress (152 s) et Playwright (156 s).
En additionnant les deux parties, Thunders rend le résultat le plus rapide, du déclenchement au résultat, face aux trois frameworks.
Comment obtenir un résultat plus rapide
Avec 10 tests à la fois, l’exécution représente l’essentiel du temps. Le moyen direct d’aller plus vite est d’exécuter plus de tests à la fois. C’est là que les deux modèles divergent.
Sur GitHub Actions, un runner standard dispose de 2 vCPU: ajouter des navigateurs en parallèle sur le même runner les met en concurrence pour le même CPU, et chaque test ralentit. Pour aller plus loin, vous payez des runners plus gros, ou vous découpez la suite en shards sur plusieurs runners. Chaque shard est une nouvelle machine: il paie à nouveau les 22 à 40 secondes de préparation et ajoute des minutes de runner à votre facture.
Sur Thunders, le nombre d’exécutions parallèles est un réglage du cluster d’exécution, dans la limite de votre offre. Les tests tournent sur la flotte de navigateurs Thunders: aucune nouvelle machine à préparer, aucune préparation à repayer. Avec 50 tests à la fois, les 50 tests passent en une seule vague.
Pourquoi Thunders est plus rapide
1. Pas de build, pas d’installation de navigateur, pas de machine à froid
Un test scripté est du code, et un runner CI hébergé est une machine neuve à chaque job. Avant le premier test, le runner doit démarrer, récupérer le dépôt, installer ou restaurer les dépendances, compiler ou transpiler le projet, et installer ou restaurer un navigateur et son driver. Un cache raccourcit cette étape, mais ne la supprime pas. Un test Thunders n’est pas un projet de code: il est stocké dans la plateforme, prêt à être exécuté. Il tourne sur une infrastructure maintenue prête, avec les navigateurs déjà en place: il n’y a rien à télécharger, compiler ou installer.
2. Un ordonnancement propriétaire
Avec un framework scripté, l’exécution parallèle est votre affaire. Vous fixez le nombre de workers, découpez la suite en shards et dimensionnez les runners. Thunders ordonnance les tests lui-même. Son planificateur lance le test suivant dès qu’un emplacement se libère: aucun emplacement n’attend le test le plus lent d’une vague. Pour exécuter plus de tests à la fois, vous modifiez un seul réglage. Vous n’écrivez aucune configuration de sharding, et vous ne repayez pas la préparation pour chaque shard.
3. La mise en cache de la logique
Les tests Thunders sont rédigés en langage naturel, et l’IA transforme chaque étape en actions sur la page. L’IA est lente quand elle doit réfléchir à chaque clic, à chaque exécution. Thunders ne fonctionne pas ainsi. La première exécution résout chaque étape, et Thunders met le résultat en cache. Les exécutions suivantes rejouent directement les actions en cache, sans appel au modèle. Thunders ne fait de nouveau appel à l’IA que lorsque la page change et que l’action en cache ne convient plus.
4. Les smart waits
Les tests scriptés attendent souvent avec des délais fixes ou de longs timeouts, parce qu’une page qui n’est pas prête fait échouer un test. Un délai fixe est toujours trop long ou trop court. Thunders attend que la page soit prête, puis agit immédiatement. Il n’attend pas un nombre fixe de secondes quand la page est déjà stable, et il n’agit pas trop tôt quand la page est encore en cours de chargement.
5. Une infrastructure distribuée conçue uniquement pour les tests web
Un runner GitHub standard est une seule machine polyvalente de 2 vCPU. Elle doit compiler le code, exécuter les scripts et faire tourner tous les navigateurs du job sur ces 2 cœurs. L’infrastructure Thunders est distribuée et fortement personnalisée, et elle n’a qu’une mission: exécuter des tests web. Les tests se répartissent sur une flotte de machines dédiées aux navigateurs: aucun test n’attend le CPU qu’utilise un autre test. Nous dimensionnons la flotte, réglons les navigateurs et exploitons toute la pile pour cette seule mission. C’est pourquoi Thunders est plus rapide non seulement sur la préparation, mais aussi sur l’exécution.
Ce que cela change au-delà du benchmark
Le benchmark mesure une exécution de 50 tests. En conditions réelles, l’écart se creuse de trois façons:
- Plus d’exécutions: une équipe pousse du code plusieurs fois par jour. Le temps de préparation d’un framework scripté revient à chaque exécution. Avec Thunders, il n’existe pas.
- Moins de relances: un test instable oblige un développeur à relancer tout le pipeline. Les smart waits et les tests auto-réparants réduisent le nombre d’exécutions qui échouent pour des raisons sans rapport avec le code.
- Moins de maintenance: un test scripté casse quand un sélecteur change, et quelqu’un doit corriger le code. Un test Thunders se répare seul quand l’interface change: l’équipe consacre son temps au produit, pas à la suite de tests.
Un résultat plus rapide, ce n’est pas seulement un meilleur chiffre sur un graphique. C’est un développeur qui reste concentré, une pull request fusionnée plus tôt et une release livrée le jour même.
La place de Thunders
Thunders est une plateforme de test par l’IA pour les tests end-to-end. Vous décrivez un test en langage naturel, Thunders l’exécute dans un vrai navigateur et le maintient opérationnel quand l’interface change. Comme le montre ce benchmark, cette souplesse ne se paie pas en vitesse. Vous obtenez votre résultat plus vite qu’avec Playwright, Selenium ou Cypress, parce que Thunders supprime la préparation qu’un framework scripté répète à chaque exécution, et exécute les tests sur une infrastructure distribuée conçue pour les tests web. Quand vous avez besoin d’un résultat encore plus rapide, vous augmentez le nombre d’exécutions parallèles d’un seul réglage, dans la limite de votre offre.
Vous pouvez le vérifier sur votre propre application: prenez les tests end-to-end qui ralentissent votre pipeline, rédigez-les dans Thunders et comparez le temps jusqu’au résultat. L’essai gratuit exécute jusqu’à 5 tests à la fois ; pour reproduire les 10 exécutions parallèles de ce benchmark, demandez une configuration Enterprise lors de votre démo.
Commencez un essai gratuit ou réservez une démo pour le constater sur votre propre application.
