TestSprite

TestSprite envoie une flotte d'agents dans votre app en direct d'un coup, qui parcourent les flux comme de vrais utilisateurs avant qu'aucun test ne soit écrit. Les tests découlent de ce que les agents trouvent, pas d'une intention devinée depuis votre code. Un test au vert reflète donc quelque chose qu'une personne pourrait réellement faire.

Importez un PRD et TestSprite en extrait une carte structurée des fonctionnalités, couvrant les flux, les dépendances et les cas limites, puis la dessine comme un graphe modifiable. Cette carte devient la référence qui guide la génération du plan, si bien que la couverture remonte à ce que votre produit est censé faire.

Le même tableau de bord couvre les tests de navigateur pilotés par Playwright et les tests d'API pilotés par Python. Pour le front-end et les tests d'API, il n'y a qu'un seul flux : le front-end reçoit les parcours utilisateur, la validation de formulaires et les flux d'authentification, et le back-end reçoit les vérifications de schéma, la gestion des erreurs et l'intégrité des données entre appels enchaînés.

Chaque échec renvoie un paquet cohérent : l'étape qui a échoué et ses voisines, des captures, des snapshots du DOM, le code du test, une hypothèse de cause racine et un correctif suggéré. Auto-Heal répare les tests d'interface quand la page change, donc les refactorisations n'inondent pas la suite de faux échecs.

Sur les projets d'API, TestSprite cartographie comment la réponse d'un appel alimente le suivant et montre chaque requête HTTP effectuée, avec requête, réponse et temps sur la même vue. Les tests indépendants tournent en parallèle et les tests dépendants attendent, tandis qu'Auto-Cleanup efface les enregistrements créés par les tests.

TestSprite vit là où vous travaillez : une CLI pour le terminal et la CI, un serveur MCP dans votre éditeur, une barrière à chaque fusion et un tableau de bord sans code pour le reste de l'équipe. Une seule suite et un seul jeu de résultats, peu importe qui a lancé l'exécution.