Automatisierte Tests für GitHub — ohne noch eine Workflow-Datei
Nahtlose Integration mit Ihren bevorzugten KI-gestützten Editoren
Keine Änderungen am Repository
TestSprite wird als GitHub App installiert und liest nur Ereignisse. Es steht neben Ihrer Pipeline, nicht darin: kein YAML zu schreiben, kein Workflow zu pflegen und nichts, was in .github/ hinzukommt.
Ausgelöst von einem echten Deployment
Wählen Sie das CI/CD-Ereignis, das nach dem Erreichbarwerden der Umgebung feuert. Eines zu wählen, das schon beim Build-Start auslöst, ist der häufigste Einrichtungsfehler — dann scheitern alle Tests an einer URL, die es noch gar nicht gibt.
Ergebnisse landen am Pull Request
Anzahl bestandener und fehlgeschlagener Tests, ein Qualitätswert, der nur auf der ausführbaren Teilmenge berechnet wird, Screenshots vom Moment des Fehlschlags und ein Korrektur-Prompt, der zum direkten Einfügen in Ihren KI-Coding-Agenten geschrieben ist.
Eine Pflichtprüfung, die Merges blockiert
Schalten Sie Block PR until tests pass ein, dann wird die TestSprite-Prüfung verpflichtend: Eine Regression hält den Merge auf, statt durchzurutschen und später aufzufallen.
Sichern Sie jeden Pull Request mit einem echten Browser ab
Ein grüner Haken sollte bedeuten, dass die ausgelieferte Anwendung funktioniert — nicht, dass eine Suite erfolgreich losgeschickt wurde. TestSprite wartet auf das echte Urteil und lässt den Job bei einem Teillauf scheitern, statt ihn durchzuwinken.
Für Teams, die auf GitHub ausliefern
Passt zu Ihrem Hoster
Jeder Anbieter, der ein Deployment an GitHub meldet und eine erreichbare URL bereitstellt: Vercel, AWS Amplify, Netlify und selbst gebaute Pipelines, die GitHub-Deployments anlegen.
Pull Request oder Push
Ein Pull-Request-Auslöser fängt Regressionen vor dem Merge ab und kommentiert am PR. Ein Push-Auslöser testet nach jedem Merge eine gemeinsame Staging- oder Dev-Umgebung und schreibt eine Commit-Prüfung. Legen Sie beide an — sie laufen unabhängig.
Oder über die CLI steuern
Sie wollen den Lauf selbst in der Hand haben? Die Open-Source-CLI leistet dasselbe von jedem CI aus, und testsprite ci init github erzeugt Ihnen den Workflow.
Kostenlose Community-Version
Wir bieten eine kostenlose Community-Version, damit sie allen offensteht.
Weltweit von Unternehmen geschätzt
"Gute Arbeit! Ziemlich cooles MCP vom TestSprite-Team! KI-Codierung + KI-Tests helfen Ihnen, mühelos bessere Software zu entwickeln!"
"TestSprite bietet eine umfangreiche Testfallgenerierung, eine klare Struktur und leicht lesbaren Code. Es unterstützt auch einfaches Online-Debugging mit der Möglichkeit, durch die Generierung neuer Testfälle schnell zu erweitern."
"Die Automatisierung von TestSprite hilft uns, eine Menge manueller Arbeit zu reduzieren. Die Entwickler können Fehler früher im Entwicklungsprozess leicht erkennen und beheben."
FAQ
Muss ich eine Workflow-Datei in mein Repository legen?
Nein. Die Integration wird vollständig in TestSprite konfiguriert und erfordert keine Änderung an Ihrem Repository. Wenn Sie den Lauf lieber aus Ihrem eigenen Workflow steuern, erzeugt testsprite ci init github einen, der die gepflegte TestSprite-Action verwendet.
Ersetzt das meinen bestehenden GitHub-Actions-Workflow?
Nein. TestSprite lauscht auf Ereignisse, die Ihr Workflow ohnehin erzeugt; es ändert oder ersetzt Ihre Pipeline nicht.
Was, wenn mein Repository nie ein Deployment erzeugt?
Dann gibt es nichts, worauf zu lauschen wäre. TestSprite wird von einem Deployment-Ereignis ausgelöst, also muss dieses Ereignis zuerst existieren. Ergänzen Sie einen Deploy-Schritt in Ihrer Pipeline, oder nutzen Sie die CLI in einem Workflow und richten Sie das Projekt auf eine URL, die Sie selbst ermitteln.
Woher kennt TestSprite die Preview-URL?
Sie hinterlegen einmal ein Muster mit Platzhaltern, die pro Lauf aufgelöst werden: {pr}, {branch}, {branch-slug}, {sha} und {short-sha}. Aus https://pr-123.example.com wird so https://pr-{pr}.example.com.
Welche Berechtigungen braucht die GitHub App?
Lesezugriff auf actions, checks, issues und metadata; Lese- und Schreibzugriff auf code, commit statuses, deployments und pull requests. Der Schreibzugriff ist das, was das Zurückschreiben der Ergebnisse an Ihre Pull Requests ermöglicht. TestSprite pusht keine Commits und ändert Ihre Workflow-Dateien nicht.
Können die Ergebnisse in einen KI-Coding-Agenten fließen?
Ja. Jeder Fehlschlag im Pull-Request-Kommentar enthält einen Korrektur-Prompt, der zum Einfügen in einen Coding-Agenten gedacht ist. Für eine vollständigere Schleife installiert testsprite setup --agent claude einen Verifikations-Skill, damit der Agent Tests selbst erstellt, ausführt und einordnet.