Le test d'API qui n'a pas besoin de navigateur.
testsprite test create --type backend planifie et exécute de vraies requêtes HTTP contre votre API en production — authentification, appels dépendants, cas limites — depuis votre terminal ou votre CI. Pas de Playwright, pas de navigateur, aucun script de test écrit à la main à garder synchronisé avec vos endpoints.
Lit la documentation d'API que vous avez déjà
Sachez ce que vous avez cassé
testsprite test rerun <testId> --output json après un changement backend vous donne un succès/échec contre l'endpoint réel — pas l'instantané d'un mock qui n'a jamais changé.
Exprimez ce que vous voulez
Pointez-le vers votre collection OpenAPI, Swagger ou Postman — ou une documentation libre — et il transforme automatiquement vos endpoints en plan de test.
Validez ce que vous avez
Les plans de test prennent en charge des étapes ordonnées d'action/assertion, pour enchaîner des appels dépendants — se connecter, puis vérifier la réponse authentifiée — comme le ferait un vrai client.
Obtenez ce qu'il vous faut
Chaque échec est un pack d'échec contenant la requête, la réponse, une hypothèse de cause racine et une suggestion de correctif — plus besoin de fouiller les logs pour savoir ce qui a cassé.
$ testsprite test create --project prj_8f2a --type backend \
--plan-from checkout-api-plan.json --run --wait --output json
✓ POST /cart/apply-promo passed 340ms
✗ POST /orders failed 510ms
→ expected 201, got 500
→ rootCause: "promo code not revalidated server-side"
$ testsprite test failure get <testId> --out ./failures
Conscient des dépendances, pas juste endpoint par endpoint
Un vrai flux d'API n'est pas une seule requête — c'est une chaîne : s'authentifier, puis récupérer, puis modifier. Les plans de test modélisent cette chaîne sous forme d'étapes ordonnées, pour qu'un test puisse dépendre du résultat de l'étape précédente.
Conçu pour les équipes qui pensent backend d'abord
Aucune surcharge liée au navigateur
Les tests backend s'exécutent comme de purs appels HTTP — aucun navigateur à démarrer, aucune dépendance à Playwright, une CI plus rapide.
Des plans de test structurés
testsprite test plan put versionne votre plan de test d'API en JSON, relisible dans une pull request comme le code qu'il teste.
Version communautaire gratuite
Propose une version communautaire gratuite, pour rester accessible à tous.
Exécutions en lot
testsprite test run --all --project <id> revérifie toute la surface de votre API en une seule commande.
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
Le CLI a-t-il besoin de ma spec d'API, ou peut-il se débrouiller seul ?
Les deux sont possibles. Pointez-le vers un fichier OpenAPI, Swagger ou Postman et il mappe directement les endpoints ; sans ça, il peut toujours planifier à partir d'une documentation libre ou de votre code existant.
Que fait réellement --type backend ?
De vraies requêtes HTTP contre votre API en production, avec gestion des dépendances — un plan de test peut enchaîner une étape d'authentification, une étape de récupération, puis une étape de modification, chaque étape étant soit une action soit une assertion.
Ai-je besoin d'un navigateur ou de Playwright pour ça ?
Non — les tests backend sont de purs appels HTTP. --type frontend est le chemin basé sur le navigateur via Playwright ; --type backend l'évite entièrement.
Que se passe-t-il quand un test d'API échoue ?
Vous recevez un pack d'échec : la requête, la réponse, une hypothèse de cause racine et une recommandation de correctif — récupérez-le avec testsprite test failure get <testId>.
Puis-je versionner mes plans de test d'API avec mon code ?
Oui — les plans de test sont en JSON. testsprite test plan put en met un à jour, et comme il s'agit juste d'un fichier, il se relit comme n'importe quel autre diff dans une pull request.