Neu: TestSprite CLI ist jetzt live!

Ein Verifizierer für den Loop — kein weiterer Mitspieler darin.

In Claude Code, Cursor oder Codex tippen Sie keine CLI-Flags — Sie sagen einfach: „Richte TestSprite für dieses Repo ein, lege eine Start-Testsuite an und führe dann einen Smoke-Test für den wichtigsten Ablauf aus." Der Agent liest Ihre Routen und Handler, erstellt die Tests und führt sie aus — ein zweiter, unabhängiger Durchgang über seine eigene Arbeit, nicht nur ein weiterer Entwurf, dem man blind vertrauen muss.

Direkt aus der CLI mit 8 Coding-Agenten verbunden

ClaudeCursorCopilotCodexWindsurfClineAntigravityKiro
Sagen Sie „Verifiziere diese Änderung mit TestSprite, bevor du sie als erledigt bezeichnest" — und meinen Sie es wörtlich. Ein entworfener, aber nie ausgeführter Testplan erfüllt diese Anweisung nicht. Nur ein Ergebnis tut das: bestanden oder fehlgeschlagen, entschieden durch tatsächliche Ausführung.

„Richte TestSprite für dieses Repo ein und lege eine Start-Testsuite an"

Der Agent liest Ihre Routen, Handler und zentralen Abläufe, erstellt ein Projekt und schreibt etwa 8–15 Tests mit konkreten, beobachtbaren Assertions — im Batch erstellt, nicht einzeln eingetippt.

„Verifiziere diese Änderung mit TestSprite, bevor du sie als erledigt bezeichnest"

Führt den Test bis zu einem Ergebnis aus — bestanden oder fehlgeschlagen — statt bei einem entworfenen Plan stehenzubleiben. Einen Test zu schreiben ist nicht dieselbe Aussage wie ihn auszuführen.

„Erstelle einen Test für den Checkout-Happy-Path und führe ihn bis zu einem Ergebnis aus"

Gezielte Abdeckung für einen einzelnen Ablauf, auf Abruf, mit derselben Disziplin — „ausführen, nicht nur entwerfen" — wie bei der vollen Suite.

Vorschlagen, was Sie brauchen

Das Failure-Bundle — Ursache, Screenshot, DOM-Snapshot, Korrekturempfehlung — ist strukturiertes JSON, sodass ein Agent es parsen und seinen nächsten Schritt entscheiden kann, ohne dass ein Mensch dazwischengeschaltet werden muss.

You: "Set up TestSprite for this repo and seed a starter test suite,
      then smoke-run the most important flow."

# the agent runs this on your behalf — you never type it:
$ testsprite setup
$ testsprite test create-batch starter-suite.json
  ✓ 11 tests created from your routes and handlers

$ testsprite test run --project prj_8f2a --ids TC_checkout,TC_login --wait
  ✓ TC_checkout_happy_path   passed
  ✓ TC_login_success         passed

„Entworfen" heißt nicht „Erledigt"

Sagen Sie „führe es bis zu einem Ergebnis aus" und meinen Sie es so — ein Testplan, der existiert, aber nie ausgeführt wurde, erfüllt diese Anweisung nicht. Nur bestanden oder fehlgeschlagen zählt, und jeder Fehlschlag kommt als strukturiertes Bundle zurück, mit dem der Agent selbst weiterarbeiten kann.

Entwickelt für unbeaufsichtigte Läufe

Liest zuerst Ihre Codebasis

Der Onboarding-Skill scannt Ihre Routen, Handler und zentralen Abläufe, bevor auch nur ein Test geschrieben wird — Abdeckung, die von dem ausgeht, was Ihr Produkt tatsächlich tut, nicht von einer Vermutung.

Stabilitäts-Scoring

testsprite test flaky <testId> sagt dem Agenten, ob ein Fehlschlag eine echte Regression oder ein instabiler Test ist — bevor ein Korrekturversuch am falschen Problem verschwendet wird.

Kostenlose Community-Version

Bietet eine kostenlose Community-Version, die uns für jeden zugänglich macht.

Mitten im Lauf abbrechen

testsprite test cancel <runId> stoppt einen laufenden Testlauf in dem Moment, in dem der Agent — oder Sie — entscheidet, dass er nicht mehr gebraucht wird.

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

Was sage ich konkret, um das einzurichten?

In Claude Code, Cursor oder einem anderen unterstützten Agenten: „Richte TestSprite für dieses Repo ein, lege eine Start-Testsuite an und führe dann einen Smoke-Test für den wichtigsten Ablauf aus." Den Rest übernimmt der Agent — keine Flags zum Auswendiglernen.

Was bedeutet „eine Start-Testsuite anlegen" konkret?

Der Agent liest Ihre Codebasis — Routen, Handler, zentrale Abläufe —, erstellt ein TestSprite-Projekt, schreibt etwa 8–15 Tests mit konkreten, beobachtbaren Assertions, legt sie im Batch an und führt nur die 2–3 wertvollsten Happy Paths aus, statt der gesamten Suite.

Warum kann der Coding-Agent nicht einfach seinen eigenen Code testen?

Er kann, aber dann bewertet er seine eigenen Hausaufgaben — seine Tests übernehmen jedes Missverständnis, das er bezüglich der Anforderungen hatte. testsprite läuft in einem separaten Kontext, steuert einen echten Browser oder macht echte API-Aufrufe, und fängt so genau die Fehlerklasse ab, die Selbsttests strukturell nicht erkennen können.

Wie stelle ich sicher, dass der Agent nicht nur einen Test entwirft und ihn für erledigt erklärt?

Sagen Sie „verifiziere diese Änderung mit TestSprite, bevor du sie als erledigt bezeichnest" oder „führe es bis zu einem Ergebnis aus." Diese Formulierung ist wichtig — ein entworfener, aber nie ausgeführter Plan erfüllt sie nicht, nur ein tatsächliches Bestehen oder Scheitern.

Was bekommt der Agent bei einem Fehlschlag zurück?

Ein strukturiertes JSON-Ergebnis mit einem vollständigen Bundle: fehlgeschlagener Schritt, Screenshot, DOM-Snapshot, Ursachenhypothese, Korrekturempfehlung — alles, was er braucht, um einen Korrekturversuch zu unternehmen, ohne zuerst einen Menschen zu fragen.

Braucht das CI, oder funktioniert es auch für einen einzelnen Lauf über Nacht?

Beides. Es ist dieselbe CLI, egal ob sie als Schritt in GitHub Actions läuft oder innerhalb einer einzelnen, lang laufenden Agenten-Sitzung auf Ihrer eigenen Maschine.

Geben Sie dem Loop Ihres Agenten einen ehrlichen Verifizierer.