API-Testing, das keinen Browser braucht.
testsprite test create --type backend plant und führt echte HTTP-Requests gegen Ihre Live-API aus — Auth, abhängige Aufrufe, Edge Cases — direkt aus Ihrem Terminal oder Ihrer CI. Kein Playwright, kein Browser, keine handgeschriebenen Testskripte, die mit Ihren Endpunkten synchron gehalten werden müssen.
Liest die API-Dokumentation, die Sie bereits haben
Sichern, was kaputtging
testsprite test rerun <testId> --output json liefert Ihnen nach einer Backend-Änderung ein Bestanden/Fehlgeschlagen gegen den echten Endpunkt — kein Snapshot eines Mocks, der sich nie verändert.
Verstehen, was Sie wollen
Verweisen Sie auf Ihre OpenAPI-, Swagger- oder Postman-Collection — oder freie Dokumentation —, und Ihre Endpunkte werden automatisch in einen Testplan überführt.
Validieren, was Sie haben
Testpläne unterstützen geordnete Aktions-/Assertion-Schritte, sodass abhängige Aufrufe verkettet werden können — einloggen, dann die authentifizierte Antwort prüfen — genau so, wie es ein echter Client tun würde.
Vorschlagen, was Sie brauchen
Jeder Fehlschlag ist ein Failure-Bundle mit dem Request, der Response, einer Ursachenhypothese und einem Korrekturvorschlag — kein Durchwühlen von Logs, um herauszufinden, was kaputt ist.
$ 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
Abhängigkeitsbewusst, nicht nur Endpunkt für Endpunkt
Echte API-Abläufe sind nicht ein einzelner Request — sie sind eine Kette: authentifizieren, dann abrufen, dann verändern. Testpläne bilden diese Kette als geordnete Schritte ab, sodass ein Test vom Ergebnis des vorherigen Schritts abhängen kann.
Entwickelt für Backend-First-Teams
Kein Browser-Overhead
Backend-Tests laufen als reine HTTP-Aufrufe — kein Browser zum Starten, keine Playwright-Abhängigkeit, schnellere CI.
Strukturierte Testpläne
testsprite test plan put versioniert Ihren API-Testplan als JSON, überprüfbar in einem Pull Request wie der Code, den er testet.
Kostenlose Community-Version
Bietet eine kostenlose Community-Version, die uns für jeden zugänglich macht.
Batch-Läufe
testsprite test run --all --project <id> verifiziert Ihre gesamte API-Oberfläche mit einem einzigen Befehl erneut.
Weltweit von Unternehmen geschätzt
"TestSprite bietet eine umfangreiche Testfallgenerierung, eine klare Struktur und leicht lesbaren Code. Es unterstützt auch einfaches Online-Debugging mit der Möglichkeit, schnell durch die Generierung neuer Testfälle zu erweitern."
"Die Automatisierung von TestSprite hilft uns, Tonnen manueller Arbeit zu reduzieren. Die Entwickler können Fehler im Entwicklungsprozess leichter und früher erkennen und beheben."
FAQ
Braucht die CLI meine API-Spezifikation, oder kann sie sich auch selbst zurechtfinden?
Beides. Verweisen Sie auf eine OpenAPI-, Swagger- oder Postman-Datei, und Endpunkte werden direkt übernommen; ohne eine solche Datei kann sie trotzdem aus freier Dokumentation oder Ihrem bestehenden Code planen.
Was führt --type backend tatsächlich aus?
Echte HTTP-Requests gegen Ihre Live-API, mit Abhängigkeitsverwaltung — ein Testplan kann einen Authentifizierungs-Schritt mit einem Abruf-Schritt und einem Veränderungs-Schritt verketten, wobei jeder Schritt entweder eine Aktion oder eine Assertion ist.
Brauche ich dafür einen Browser oder Playwright?
Nein — Backend-Tests sind reine HTTP-Aufrufe. --type frontend ist der Playwright-basierte Browser-Pfad; --type backend überspringt ihn komplett.
Was passiert, wenn ein API-Test fehlschlägt?
Sie erhalten ein Failure-Bundle: den Request, die Response, eine Ursachenhypothese und eine Korrekturempfehlung — abrufbar mit testsprite test failure get <testId>.
Kann ich meine API-Testpläne zusammen mit meinem Code versionieren?
Ja — Testpläne sind JSON. testsprite test plan put aktualisiert einen Plan, und da es nur eine Datei ist, lässt er sich wie jeder andere Diff in einem Pull Request reviewen.