Wie Sie Vercel-Preview-Deployments 2026 automatisch testen

Die kurze Antwort

Sie fügen keine Workflow-Datei hinzu und schreiben kein Skript, das die Preview-URL aus Ihren Build-Logs herauskratzt. TestSprite installiert sich als GitHub App, lauscht auf das Deployment-Event, das Ihre Pipeline bereits erzeugt, ermittelt die Preview-URL anhand eines Musters, das Sie einmal festlegen, führt Ihre Tests dagegen aus und postet das Ergebnis als Kommentar auf dem Pull Request zurück.

Die Einrichtung dauert etwa zehn Minuten, erfordert Admin-Rechte zur Installation einer GitHub App und keine Änderungen an Ihrem Repository.

Voraussetzung: Bestätigen Sie, dass der Pull Request ein Deployment erzeugt

TestSprite löst über ein Deployment-Event aus, daher muss dieses Event existieren, bevor irgendetwas anderes funktioniert. Öffnen Sie einen bestehenden Pull Request und bestätigen Sie, dass ein Deployment mit einer anklickbaren URL aufgeführt ist, öffnen Sie dann diese URL und prüfen Sie, ob die Preview-Umgebung tatsächlich lädt.

Bei Vercel erscheint das als Bot-Kommentar auf dem Pull Request, der das Projekt auflistet, ein Ready-Status und ein Link zur Preview. AWS Amplify, Netlify und selbstgehostete Pipelines, die GitHub-Deployments erzeugen, liefern alle das gleiche Signal in ihrem eigenen Format — entscheidend ist, dass ein Deployment existiert und seine URL erreichbar ist.

Schritt 1 — GitHub mit Ihrem Workspace verbinden

Dies ist eine einmalige Einrichtung pro Workspace. Gehen Sie in TestSprite zu Workspace Settings → Integrations, suchen Sie die Zeile GitHub und klicken Sie auf Connect. Sie werden zu GitHub weitergeleitet, um die Organisation oder das persönliche Konto auszuwählen, dem das Repository gehört, wählen dann All repositories oder Only select repositories und klicken auf Install & Authorize.

Die angeforderten Berechtigungen sollten Sie kennen, bevor Sie sie genehmigen:

Schreibzugriff wird verwendet, um Testergebnisse an Ihre Pull Requests und Commits zurückzumelden. TestSprite pusht keine Commits und verändert keine Ihrer Workflow-Dateien. Wenn Ihre Organisation während der Installation nicht aufgelistet wird, haben Sie keine Berechtigung, GitHub Apps dafür zu installieren — ein Organisationsinhaber muss dies genehmigen.

Schritt 2 — Das Repository mit einem Projekt verbinden

Öffnen Sie das TestSprite-Projekt, das Sie verbinden möchten, gehen Sie zum Tab GitHub Action und klicken Sie auf Connect GitHub Action. Wählen Sie dann, wie Tests ausgelöst werden sollen:

Ein Trigger reicht zum Start. Sie können auch beide anlegen — sie laufen unabhängig voneinander.

Schritt 3 — Das Event auswählen, das "Deployment fertig" bedeutet

Wählen Sie den Tab Pull Request, fügen Sie die URL eines bestehenden Pull Requests mit einem funktionierenden Preview-Deployment ein und klicken Sie auf Detect Events. TestSprite listet die CI/CD-Events auf, die es auf diesem Pull Request gefunden hat — GitHub-Actions-Checks, Bot-Kommentare von Vercel oder Amplify, Workflow-Läufe — und Sie wählen, welches davon einen Lauf startet.

Wählen Sie das Event, das nachdem das Deployment live und die URL erreichbar ist auslöst. Das ist der häufigste Fehler bei der Einrichtung: Ein Event, das beim Build-Start auslöst, führt Ihre Tests gegen eine URL aus, die noch nicht bereit ist, und jeder Test schlägt fehl.

Schritt 4 — Das Ziel-URL-Muster ausfüllen

Jeder Hosting-Anbieter benennt Preview-URLs anders, daher teilen Sie TestSprite mit, wie die URL für einen gegebenen Pull Request zu konstruieren ist. Fünf Platzhalter stehen zur Verfügung:

Gleichen Sie das Muster Zeichen für Zeichen mit einer echten Preview-URL ab:

Vercels Standard-Preview-Hostnamen werden aus dem Branch gebildet, weshalb {branch-slug} dort üblicherweise der richtige Platzhalter ist statt {pr}. Wenn Ihr Host zufällige Subdomains ohne erkennbares Muster erzeugt, richten Sie stattdessen eine stabile Alias-URL für die Preview-Umgebung ein und verwenden Sie diese.

Ein Push-Trigger benötigt überhaupt kein Muster — er läuft gegen die konfigurierte URL der von Ihnen gewählten TestSprite-Umgebung, also wählen Sie Dev für dev oder Production für main.

Schritt 5 — Ein Test-Event senden, bevor Sie speichern

Klicken Sie auf Send Test Event. Dies führt Ihre Tests genau wie ein echter Trigger gegen den Beispiel-Pull-Request aus, sodass Sie den gesamten Ablauf vorab prüfen können, bevor Sie sich darauf festlegen. Warten Sie etwa 30 Sekunden und kehren Sie dann zum Pull Request auf GitHub zurück — ein TestSprite-Kommentar erscheint.

Öffnen Sie die URL in diesem Kommentar, bevor Sie fortfahren. Bestätigen Sie, dass sie erreichbar ist und auf die erwartete Umgebung zeigt. Falls sie falsch ist, korrigieren Sie das Muster und senden Sie ein weiteres Test-Event, statt auf den nächsten Pull Request zu warten, um es herauszufinden. Sobald der Lauf abgeschlossen ist, aktualisiert TestSprite denselben Kommentar mit dem Ergebnis.

Wenn das Test-Event korrekt aussieht, klicken Sie auf Create Trigger. Er erscheint in der Triggers-Liste als Active markiert und läuft automatisch bei jedem zukünftigen Pull Request. Zwei optionale Umschalter sind es wert, bewusst gesetzt zu werden:

Wenn Ihre Preview hinter Deployment Protection sitzt

Dies ist das Fehlerbild, das wie eine funktionierende Einrichtung aussieht. Mit aktiviertem Vercel Deployment Protection sitzt jede Preview-URL hinter einer Authentifizierungsschranke, und ein externer Tester erhält die Login-Seite statt Ihrer Anwendung. Die Tests werfen keinen Fehler — sie beschreiben eine Seite, die niemand erwartet hat.

Der Check aus Schritt 5 fängt das ab: Öffnen Sie die URL aus dem TestSprite-Kommentar in einem privaten Fenster. Wenn Sie einen Vercel-Login-Bildschirm sehen, ist der Schutz aktiv. Die zwei Wege nach vorn sind, den Schutz für die Preview-Umgebung zu deaktivieren, oder Vercels Protection Bypass for Automation zu nutzen, das ein Secret erzeugt, das Vercel sowohl als x-vercel-protection-bypass-Query-Parameter als auch als Header akzeptiert. Da das Ziel-URL-Muster nur eine URL ist, kann die Query-Parameter-Form daran angehängt werden:

https://app-git-{branch-slug}-team.vercel.app?x-vercel-protection-bypass=YOUR_SECRET

Generieren Sie das Secret unter Project Settings → Deployment Protection → Protection Bypass for Automation. Seien Sie hierbei bewusst — es speichert ein Bypass-Secret in einem Einstellungsfeld, weshalb das Deaktivieren des Schutzes für Preview-Umgebungen die sauberere Option ist, wenn Ihre Previews nichts Sensibles enthalten.

Das Ergebnis lesen

Wenn ein Lauf abgeschlossen ist, aktualisiert TestSprite seinen Pull-Request-Kommentar — oder Commit-Check — mit dem Ergebnis. Der Kommentar ist strukturiert, und die letzte Zeile ist die wichtigste, wenn ein KI-Agent den Code geschrieben hat:

Jedes Ergebnis verlinkt zurück auf den vollständigen Report in TestSprite.

Ihre Einrichtung überprüfen

Bevor Sie sich auf die Integration verlassen, bestätigen Sie alle fünf:

1. Die GitHub-Integration zeigt in Ihrem Workspace als Connected

2. Das Repository erscheint im Tab GitHub Action des Projekts

3. Ein Trigger ist aufgeführt und aktiviert

4. Ein Test-Event hat einen TestSprite-Kommentar (Pull Request) oder Check (Push) erzeugt

5. Die URL in diesem Kommentar oder Check öffnet die korrekt deployte Umgebung

Fehlersuche

Die Kommandozeilen-Alternative

Die GitHub App ist die richtige Antwort, wenn Ihre Pipeline bereits Deployments erzeugt. Wenn Sie den Lauf lieber aus Ihrem eigenen Workflow heraus steuern möchten — oder überhaupt nicht auf GitHub sind — erledigt die Open-Source-TestSprite-CLI denselben Job von jedem CI-System aus. Sie ist kostenlos installierbar und Apache-2.0-lizenziert:

npm install -g @testsprite/testsprite-cli
testsprite setup

Richten Sie ein Projekt auf eine URL aus, die Sie bereits aufgelöst haben, und führen Sie die Suite zu einem Urteil aus:

testsprite project update prj_abc123 --url "$PREVIEW_URL"
testsprite test run --all --project prj_abc123 --wait --output json
#   exit 0 = alles bestanden, exit 1 = etwas ist kaputt

testsprite ci init github erstellt für diesen Weg ein Workflow-Grundgerüst, und die CLI braucht nur TESTSPRITE_API_KEY in der Umgebung, also fügt sie sich genauso leicht in CircleCI, GitLab, Jenkins oder Azure Pipelines ein. Verwenden Sie --report junit --report-file <path> für einen Sidecar, den diese Systeme nativ einlesen.

Wenn die Abläufe, die Sie interessieren, hinter dem eigenen Login Ihrer Anwendung liegen, speichern Sie ein Testkonto im Projekt, damit Läufe sich authentifizieren können. Beide Flags sind zusammen erforderlich:

testsprite project update prj_abc123 \
  --username qa@example.com \
  --password-file ./.secrets/qa-password

Häufig gestellte Fragen