Führen Sie Tests automatisch bei jedem GitHub-Deployment aus.
Verbinden Sie ein Repository einmal, und TestSprite achtet auf das GitHub-Ereignis, das bedeutet: „der neue Build ist deployt und die URL ist live" — führt dann Ihre Testsuite dagegen aus und meldet das Ergebnis als Pull-Request-Kommentar oder Commit-Check zurück. Keine Workflow-Datei, keine Änderungen an Ihrer Pipeline.
Funktioniert mit jedem Anbieter, der auf GitHub deployt
Ausgelöst durch Ihre CI/CD
Ein Deploy, ein Workflow-Lauf oder ein Status-Check — legen Sie das CI/CD-Ereignis, das Sie bereits haben, als Signal für „bereit zum Testen" fest.
Ergebnisse landen direkt im PR
Pass/Fail, fehlgeschlagene Schritte und ein Replay-Link werden als PR-Kommentar oder Commit-Check gepostet — Reviewer sehen Qualität direkt neben dem Code.
Merges mit einem Status-Check blockieren
Aktivieren Sie „PR blockieren, bis Tests bestehen", und ein erforderlicher Check stoppt Merges, solange Regressionen offen sind.
Keine Änderungen an Workflow-Dateien
Alles wird innerhalb von TestSprite konfiguriert. Ihr Repository, Ihr .github/workflows und Ihre bestehende Pipeline bleiben unangetastet.
1. Ihre CI/CD-Pipeline baut und deployt Ihre App
→ erzeugt ein Deployment-Ereignis in GitHub
2. TestSprite empfängt dieses Ereignis über die
GitHub-App-Integration
3. TestSprite löst die Ziel-URL auf — aus dem
Deployment selbst oder aus einem von Ihnen
definierten URL-Muster
(unterstützt {pr}, {branch}, {branch-slug}, {sha})
4. TestSprite führt Ihre Tests aus und meldet die
Ergebnisse als PR-Kommentar oder Commit-Check
an GitHub zurück
Deployen Sie mit einem Signal, dem Sie vertrauen können
Jedes Deployment — eine PR-Vorschau oder ein Merge nach Staging — wird gegen die echte, live URL getestet. Kein Mock, keine Vermutung.
Zwei Wege, einen Lauf auszulösen
Pull Request
Am besten geeignet, um Regressionen vor dem Merge zu erkennen. TestSprite testet das Preview-Deployment des PR und kommentiert das Ergebnis direkt im PR.
Push auf einen Branch
Am besten geeignet, um eine gemeinsam genutzte Umgebung wie Staging oder Dev nach jedem Merge zu testen. Ergebnisse landen als Check am Commit.
Beide unabhängig voneinander laufen lassen
Legen Sie einen PR-Trigger und einen Push-Trigger für dasselbe Repository an — sie laufen nach ihrem eigenen Zeitplan, ohne sich gegenseitig zu beeinflussen.
Fix-Prompts, sofort einsatzbereit
Jeder Fehlschlag enthält einen vorgeschlagenen Fix-Prompt, der die wahrscheinliche Ursache beschreibt — kopieren Sie ihn direkt in Ihren KI-Coding-Agenten.
Weltweit von Unternehmen vertraut
„TestSprite bietet umfangreiche Testfallgenerierung, klare Struktur und gut lesbaren Code. Es unterstützt außerdem einfaches Online-Debugging mit der Möglichkeit, durch das Generieren neuer Testfälle schnell zu erweitern."
„Die Automatisierung von TestSprite hilft uns, jede Menge manuelle Arbeit einzusparen. Die Entwickler können Bugs so leichter und früher im Entwicklungsprozess erkennen und beheben."
FAQ
Ersetzt das meinen bestehenden GitHub-Actions-Workflow?
Nein. TestSprite hört auf Ereignisse, die Ihr Workflow bereits erzeugt — ein Deploy, ein Build, ein Status-Check — und reagiert darauf. Es verändert oder ersetzt Ihre Pipeline nicht, und es wird keine Workflow-Datei zu Ihrem Repository hinzugefügt.
Welche Berechtigungen benötigt die GitHub App?
Lesezugriff auf Actions, Checks, Issues und Metadaten; Lese- und Schreibzugriff auf Code, Commit-Status, Deployments und Pull Requests. Der Schreibzugriff wird ausschließlich genutzt, um Testergebnisse als PR-Kommentare oder Commit-Checks zurückzumelden — TestSprite pusht keine Commits und verändert keine Workflow-Dateien.
Welche Hosting-Anbieter werden unterstützt?
Jeder Anbieter, der ein Deployment an GitHub meldet und eine erreichbare URL bereitstellt — darunter Vercel, AWS Amplify, Netlify sowie selbst gehostete Pipelines, die GitHub-Deployments erzeugen.
Was, wenn meine Preview-URLs eine zufällige Subdomain statt der PR-Nummer verwenden?
Das URL-Muster-Feld erwartet ein vorhersagbares Muster mit Platzhaltern wie {pr}, {branch}, {branch-slug} und {sha}. Wenn Ihr Host unvorhersagbare Subdomains erzeugt, konfigurieren Sie stattdessen eine stabile Alias-URL für die Preview-Umgebung und verweisen Sie TestSprite darauf.
Was erscheint im Ergebnis?
Eine Kopfzahl mit Pass/Fail/Blocked, ein Qualitätsscore, berechnet auf der ausführbaren Teilmenge der Suite (blockierte Fälle werden separat gemeldet, da sie meist eher eine Lücke in der Testumgebung als eine Produktregression anzeigen), vollständige Erwartet-vs-Beobachtet-Details mit einem Screenshot für jeden Fehlschlag, sowie ein sofort kopierbarer Fix-Prompt für Ihren Coding-Agenten.
Geben Sie jedem Deployment automatisch einen echten Test.
Verbinden Sie ein Repository einmal. TestSprite übernimmt den Rest — keine Workflow-Datei, keine Änderungen an Ihrer Pipeline, und ein Kommentar oder Check bei jedem PR und Push.