Sichern Sie Ihre CI/CD-Pipeline mit einer KI-Testing-CLI ab.
Integrieren Sie testsprite in GitHub Actions, GitLab CI oder jede Pipeline, die einen Shell-Schritt ausführen kann. Die CLI authentifiziert sich über eine Umgebungsvariable, führt Ihre Suite gegen eine echte, deployte Umgebung aus und beendet sich mit einem stabilen, vorhersehbaren Code — damit ein kaputter Build den Build zum Scheitern bringt, nicht erst das nächste Standup.
Läuft in jeder CI, jedem Runner, jeder Shell
Von Grund auf nicht-interaktiv
TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude — keine Prompts, kein Browser-Login, funktioniert in jedem Headless-Runner.
Ein Schritt, jede Pipeline
testsprite test run --all --project <id> --wait --output json als einzelner CI-Schritt — parsen Sie das JSON, oder prüfen Sie einfach den Exit-Code.
Vorhersehbare Exit-Codes
Stabile, dokumentierte Exit-Codes bedeuten, dass Ihre Pipeline einen Merge auf Basis eines echten Ergebnisses absichern kann — statt Freitext-Logs zu parsen und zu raten, was passiert ist.
Dry-Run, bevor Sie committen
--dry-run testet Ihre Pipeline-Logik offline mit Testdaten, sodass Sie den Schritt verkabeln können, bevor er auf eine Live-Umgebung trifft.
# .github/workflows/verify.yml
- name: Verify with TestSprite
env:
TESTSPRITE_API_KEY: ${{ secrets.TESTSPRITE_API_KEY }}
run: |
npm install -g @testsprite/testsprite-cli
testsprite setup --from-env --yes
testsprite test run --all --project prj_8f2a --wait --output json
# exits non-zero on a real failure — the merge gate fails with it
Geben Sie dem Merge-Gate eine echte Bedeutung
Ein Build, der besteht, weil er nie wirklich geprüft hat, ist kein bestandener Build. Jeder Pipeline-Lauf testet Ihre tatsächlich deployte Umgebung — echter Browser, echte API-Aufrufe — und scheitert aus einem echten Grund.
Entwickelt für jede Phase der Pipeline
PR, Nightly oder Release
Führen Sie die volle Suite bei jedem PR aus, ein kleineres Smoke-Set nachts, oder alles vor einem Release — derselbe Befehl, nur mit anderem --project und Plan.
Batch-Wiederholungen
testsprite test rerun --all --project <id> verifiziert nach einem auffällig instabilen Lauf alles erneut, ohne die gesamte Pipeline neu anzustoßen.
Kostenlose Community-Version
Bietet eine kostenlose Community-Version, die uns für jeden zugänglich macht.
Zwei Läufe vergleichen
testsprite test diff <runId1> <runId2> zeigt genau, was sich zwischen einem bestandenen und einem fehlgeschlagenen Build geändert hat.
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
Wie authentifiziert sich die CLI in einem Headless-CI-Runner?
Legen Sie TESTSPRITE_API_KEY als Secret an und führen Sie dann testsprite setup --from-env --yes --agent claude aus (oder mit dem Agenten Ihrer Wahl). Kein interaktiver Prompt, kein Browser-Login — genau dafür ist es gebaut.
Funktioniert es speziell mit GitHub Actions?
Ja, und mit jeder CI, die einen Shell-Schritt ausführen kann — GitLab CI, CircleCI, Jenkins, Buildkite. Es ist eine Node.js-CLI, die per npm installiert wird; wenn Ihr Runner das kann, kann er auch TestSprite ausführen.
Worauf sichert die Pipeline eigentlich ab?
Auf einen echten Testlauf gegen Ihre deployte Umgebung — Browser-Tests über Playwright, API-Tests mit Abhängigkeitsverwaltung — zurückgemeldet mit einem stabilen, dokumentierten Exit-Code. Ihr bestehender „Job bei Non-Zero fehlschlagen lassen"-Schritt funktioniert einfach weiter.
Kann ich die Pipeline-Verkabelung testen, bevor sie live ist?
Ja — --dry-run testet Ihre Testlogik offline gegen Testdaten, sodass Sie bestätigen können, dass der Schritt korrekt verkabelt ist, bevor er auf eine echte Umgebung zeigt.
Was passiert, wenn CI eine echte Regression erkennt?
Sie erhalten ein Failure-Bundle (fehlgeschlagener Schritt, Screenshot, DOM-Snapshot, Ursachenhypothese, Korrekturempfehlung), das diesem Lauf zugeordnet ist — abrufbar mit testsprite test failure get <testId> aus den Job-Logs oder einem Folgeschritt.