Testen Sie jeden Pull Request, bevor er gemergt wird.
Sobald ein Pull Request ein Preview-Deployment erhält, testet TestSprite genau diese URL und kommentiert das Ergebnis im PR — bestanden, fehlgeschlagen und ein Fix-Prompt für Ihren Coding-Agenten. Aktivieren Sie einen erforderlichen Check, und Merges warten, bis er grün ist.
Funktioniert mit jedem Anbieter, der ein Preview-Deployment veröffentlicht
Wartet auf die echte Preview
TestSprite reagiert auf das Deployment-Ereignis, nicht auf den Build-Start — so wird nie eine URL getestet, bevor sie tatsächlich live ist.
Kommentiert direkt im PR
Ergebnisse werden als Kommentar gepostet: Anzahl bestandener/fehlgeschlagener Tests als Kurzübersicht, ein Qualitätswert und vollständige Details zu jedem Fehlschlag.
Merge optional blockieren
Aktivieren Sie „Block PR until tests pass“, um den TestSprite-Check zur Pflicht zu machen — kein Merge über eine offene Regression hinweg.
Draft-PRs, Ihre Wahl
Beziehen Sie Draft-Pull-Requests in den Trigger ein, oder warten Sie, bis ein PR als bereit zur Überprüfung markiert ist — Sie entscheiden.
Target URL pattern examples:
https://pr-123.example.com
→ https://pr-{pr}.example.com
https://app-git-login-fix-team.vercel.app
→ https://app-git-{branch-slug}-team.vercel.app
Placeholders: {pr} {branch} {branch-slug} {sha} {short-sha}
Geben Sie Reviewern ein echtes Signal
Ein grüner Haken, der die live geschaltete Preview nie berührt hat, ist eine Vermutung im Gewand der Gewissheit. Der Kommentar von TestSprite spiegelt wider, was tatsächlich passiert ist, als ein echter Browser die echte URL aufgerufen hat.
Was im PR landet
Kurzübersicht
Wie viele Tests bestanden, fehlgeschlagen oder blockiert wurden — blockierte Fälle werden separat ausgewiesen, da sie meist eine Lücke in der Testumgebung bedeuten, keine Regression.
Fehlerdetails
Jeder Fehlschlag lässt sich aufklappen und zeigt, was erwartet wurde, was beobachtet wurde, und einen Screenshot vom Moment des Fehlschlags.
Vorgeschlagener Fix-Prompt
Ein sofort kopierbarer Prompt, der die wahrscheinliche Ursache beschreibt — fügen Sie ihn direkt in Cursor, Claude Code oder Ihren bevorzugten Coding-Agenten ein.
Kostenlose Community-Version
Bietet eine kostenlose Community-Version, die uns für alle zugänglich macht.
Von Unternehmen weltweit vertraut
„Gute Arbeit! Ziemlich cooler MCP vom TestSprite-Team! KI-Coding + KI-Testing hilft Ihnen, mühelos bessere Software zu bauen!“
„Die Automatisierung von TestSprite spart uns enorm viel manuelle Arbeit. Die Entwickler können Bugs so viel früher im Entwicklungsprozess erkennen und beheben.“
FAQ
Was muss erfüllt sein, damit das funktioniert?
Ihre Pull Requests brauchen ein eigenes Preview-Deployment mit einer erreichbaren URL — öffnen Sie einen bestehenden PR, bestätigen Sie, dass ein Deployment aufgeführt ist, und öffnen Sie diese URL, um zu prüfen, ob sie lädt. Erscheint kein Deployment auf Ihrem PR, hat TestSprite nichts, worauf es reagieren könnte, bis Ihre CI/CD-Pipeline zuerst behoben ist.
Wie verhindere ich, dass der Check auslöst, bevor die Preview bereit ist?
Wählen Sie das CI/CD-Ereignis, das nach dem Live-Schalten des Deployments ausgelöst wird, nicht eines, das beim Build-Start feuert. TestSprite listet die auf einem Beispiel-Pull-Request erkannten Ereignisse auf, damit Sie das richtige wählen und vermeiden können, eine noch nicht bereitstehende URL zu testen.
Kann ich verlangen, dass der Check besteht, bevor gemergt werden darf?
Ja — aktivieren Sie „Block PR until tests pass“ beim Erstellen des Triggers, und der TestSprite-Check wird zur Pflicht, wodurch Merges blockiert werden, solange Tests fehlschlagen.
Fügt das eine Workflow-Datei zu meinem Repository hinzu?
Nein. Der Trigger wird vollständig innerhalb von TestSprite konfiguriert. Ihrem Repository wird nichts hinzugefügt, und Ihre bestehenden GitHub-Actions-Workflows bleiben unberührt.
Was, wenn meine Preview-URL keinem vorhersehbaren Muster folgt?
Konfigurieren Sie eine stabile Alias-URL für die Preview-Umgebung, falls Ihr Hosting-Anbieter zufällige Subdomains generiert, und richten Sie das URL-Muster stattdessen darauf aus — es muss anhand der PR-Nummer, des Branches oder des Commit-SHA vorhersehbar sein.
Hören Sie auf, auf Verdacht zu mergen.
Verbinden Sie ein Repository einmal. Jeder Pull Request wird automatisch gegen sein echtes Preview-Deployment getestet.