Testen Sie jede Netlify-Preview vor dem Merge
Nahtlose Integration mit Ihren bevorzugten KI-gestützten Editoren
Keine Workflow-Datei
TestSprite wird als GitHub App installiert und liest nur Ereignisse. Es steht damit neben Ihrer Netlify-Pipeline, nicht darin. In .github/ kommt nichts hinzu, und Ihre bestehenden Workflows bleiben unangetastet.
Ein URL-Muster statt eines Scrapers
Netlifys Deploy-Preview-URLs werden aus der Pull-Request-Nummer gebildet, deshalb ist meist {pr} der gesuchte Platzhalter. Die Platzhalter werden pro Lauf aufgelöst: {pr}, {branch}, {branch-slug}, {sha} und {short-sha}. Aus https://deploy-preview-123--site.netlify.app wird also https://deploy-preview-{pr}--site.netlify.app.
Prüfen, bevor Sie speichern
Send Test Event führt den gesamten Ablauf gegen einen Beispiel-Pull-Request aus, genau wie ein echter Auslöser. Nach rund 30 Sekunden erscheint der Kommentar: Öffnen Sie die darin genannte URL und vergewissern Sie sich, dass es die erwartete Umgebung ist, bevor Sie den Auslöser anlegen.
Ein Korrektur-Prompt statt nur eines roten Häkchens
Jeder Fehlschlag lässt sich aufklappen und zeigt, was erwartet wurde, was beobachtet wurde, einen Screenshot vom Moment des Bruchs und einen Korrektur-Prompt, der zum direkten Einfügen in Ihren KI-Coding-Agenten geschrieben ist.
Fangen Sie es in der Preview ab, nicht in der Produktion
Ein Preview-Deployment ist der letzte Ort, an dem eine Regression billig zu beheben ist. Schalten Sie Block PR until tests pass ein, dann wird die Prüfung verpflichtend und ein kaputter Ablauf hält den Merge auf, statt ausgeliefert und von einem Nutzer gefunden zu werden.
Für Teams, die auf Netlify ausliefern
Pull Request oder Branch
Ein Pull-Request-Auslöser testet jede Preview und kommentiert am PR. Ein Push-Auslöser testet nach jedem Merge eine gemeinsame Staging- oder Produktionsumgebung und schreibt eine Commit-Prüfung. Beides kann nebeneinander laufen.
Web-Oberfläche und APIs zusammen
Echte Browser-Abläufe gegen die ausgelieferte Preview plus Vertragstests der Backend-API. Fassen Sie beides in einer Testliste zusammen, dann deckt ein einziges Tor das gesamte Deployment ab.
Oder über die CLI steuern
Die Open-Source-CLI leistet dasselbe von jedem CI-System aus: kostenlos installierbar, Apache-2.0, und sie braucht nur einen API-Schlüssel in der Umgebung.
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 hinzufügen?
Nein. Die Integration wird vollständig in TestSprite konfiguriert und erfordert keine Änderung an Ihrem Repository. Sie lauscht auf die Deployment-Ereignisse, die Netlify ohnehin meldet.
Wie findet TestSprite die Netlify-Preview-URL?
Sie hinterlegen einmal ein URL-Muster. Netlifys Deploy-Preview-URLs werden aus der Pull-Request-Nummer gebildet, deshalb ist meist {pr} der gesuchte Platzhalter. Gleichen Sie das Muster Zeichen für Zeichen mit einer echten Preview-URL ab und bestätigen Sie mit Send Test Event, dass es korrekt aufgelöst wird, bevor Sie speichern.
Was, wenn die Preview-URL einen unvorhersehbaren Hash enthält?
Das Musterfeld erwartet etwas Vorhersehbares. Erzeugt Ihr Anbieter zufällige Subdomains ohne stabilen Anhaltspunkt, richten Sie für die Preview-Umgebung eine Alias-URL ein und richten Sie das Muster darauf aus.
Funktioniert das neben Deploy Previews auch mit Netlifys Branch-Deploys?
Ja. Ein Pull-Request-Auslöser deckt die Deploy Previews ab; ein Push-Auslöser deckt Branch-Deploys ab und läuft gegen die konfigurierte URL der von Ihnen gewählten TestSprite-Umgebung — dort ist also kein URL-Muster pro Lauf nötig.
Was testet TestSprite tatsächlich?
Die Oberfläche von Webanwendungen in einem echten Browser in der Cloud sowie Backend-APIs. Es steuert keine nativen iOS- oder Android-Oberflächen, keine Desktop-Anwendungen und keine Emulatoren.
Ist es kostenlos?
Die Open-Source-CLI ist kostenlos installierbar und steht unter Apache-2.0, dazu gibt es eine kostenlose Community-Version. Die Testausführung läuft in der Cloud und verbraucht Workspace-Credits: 0,5 pro Frontend-Lauf und 0,2 pro Backend-Lauf.