Tout test au rouge n'est pas forcément un vrai bug.
Un test qui échoue une fois puis réussit à la relance n'est pas la preuve qu'une fonctionnalité marche — mais ce n'est pas non plus la preuve qu'elle est cassée. testsprite test flaky <testId> donne à cet échec un score de stabilité au lieu d'un haussement d'épaules.
Intégré au même CLI que vous utilisez déjà
Sachez ce que vous avez cassé
testsprite test flaky <testId> effectue une passe de stabilité et vous indique si un échec est probablement une vraie régression ou une fragilité du test — avant que quiconque ne passe du temps à le traquer.
Exprimez ce que vous voulez
L'évaluation d'instabilité fonctionne sur n'importe quel test — généré ou téléversé via test code put — elle s'applique donc aussi à votre suite existante, pas seulement aux nouveaux tests.
Validez ce que vous avez
Les scores de stabilité proviennent d'exécutions répétées réelles contre votre environnement en production, pas d'une supposition heuristique issue d'une analyse statique.
Obtenez ce qu'il vous faut
Un test signalé comme instable reçoit quand même un pack d'échec — pour que vous puissiez voir si le bruit vient d'un problème de timing, d'une dérive de sélecteur, ou d'un souci d'environnement.
$ testsprite test flaky TC_checkout_promo Running stability pass... 4/5 runs passed — stability score: 0.80 → likely flaky, not a regression $ testsprite test flaky TC_orders_create Running stability pass... 1/5 runs passed — stability score: 0.20 → likely a real regression
Ne gaspillez pas une tentative de correction sur le mauvais problème
Un agent — ou une personne — qui traite chaque test au rouge comme un vrai bug gaspille des cycles à traquer du bruit. Le score de stabilité fait la différence entre « à examiner » et « à ignorer ».
Conçu pour les suites devenues bruyantes
Fonctionne sur n'importe quel test
Généré ou téléversé, peu importe — test flaky fonctionne sur n'importe quel identifiant de test de votre projet.
Réinjecté dans la boucle
Un agent qui vérifie des résultats de test peut appeler test flaky avant de décider si un échec nécessite une correction ou juste une relance.
Version communautaire gratuite
Propose une version communautaire gratuite, pour rester accessible à tous.
Se combine avec le diff
Utilisez testsprite test diff avec le score de stabilité pour voir exactement ce qui a changé entre les bonnes exécutions et la mauvaise.
Approuvé par des entreprises du monde entier
"TestSprite offre une génération de cas de test riche, une structure claire et un code facile à lire. Il prend également en charge le débogage en ligne simple avec la possibilité de s'étendre rapidement en générant de nouveaux cas de test."
"L'automatisation de TestSprite nous aide à réduire des tonnes de travail manuel. Les développeurs peuvent facilement détecter et résoudre les bugs plus tôt dans le processus de développement."
FAQ
Que mesure réellement testsprite test flaky ?
Il exécute le test plusieurs fois contre votre environnement en production et renvoie un score de stabilité — à quel point il réussit de façon constante — au lieu de se fier au résultat d'une seule exécution.
En quoi est-ce différent d'une simple relance du test ?
Relancer une fois et se fier au résultat obtenu, ce n'est pas un score, c'est un pile ou face. Le score de stabilité effectue suffisamment de passes pour vous donner un vrai chiffre sur lequel raisonner.
Est-ce que ça fonctionne sur les tests que j'ai écrits moi-même, pas seulement les tests générés ?
Oui — le score d'instabilité fonctionne sur n'importe quel test de votre projet, y compris ceux téléversés avec test code put.
Que faire d'un faible score de stabilité ?
Traitez-le comme une vraie régression qui mérite d'être examinée — récupérez le pack d'échec avec test failure get pour voir ce qui s'est réellement passé.
Et un score de stabilité élevé sur une exécution qui a quand même échoué une fois ?
C'est plus probablement une fragilité du test — timing, dérive de sélecteur, environnement — qu'un bug produit. Cela vaut la peine de corriger le test, pas forcément l'application.