Cursor-Bugs: So finden Sie sie vor dem Merge

Warum ein Cursor-Bug kein gewöhnlicher Bug ist

Menschen, die dieselbe Änderung schreiben, bringen Kontext mit, den der Editor nie zu sehen bekommt. Sie erinnern sich daran, dass das Einstellungs-Panel aus einem Cache liest, der invalidiert werden muss, dass der Upload-Button deaktiviert bleibt, bis eine Datei ausgewählt ist, dass ein bestimmter Endpunkt ein leeres Array statt eines 404 zurückgibt, wenn nichts passt. Cursor arbeitet mit den Dateien, die Sie geöffnet haben, und dem Text, den Sie getippt haben. Alles außerhalb dieses Ausschnitts ist geraten.

Der Fehlermodus ist also keine fehlerhafte Syntax. Es ist eine Änderung, die lokal korrekt und global falsch ist. Die Funktion tut genau das, was sie verspricht. Sie wird zum falschen Zeitpunkt aufgerufen, oder sie lässt ein Stück Zustand zurück, oder sie geht von einer Struktur aus, die die API seit zwei Sprints nicht mehr zurückgibt.

Unit-Tests fangen das nicht ab, weil sie gegen dieselben Annahmen geschrieben sind wie der Code selbst. Wenn der Agent beides geschrieben hat, stimmen die beiden miteinander überein – und mit Ihrem Produkt nicht.

Woher Cursor-Bugs tatsächlich kommen

Drei Stellen sind für den Großteil verantwortlich.

Allen gemeinsam ist: Sichtbar werden sie nur, wenn die Anwendung läuft und jemand sie benutzt. Beim Lesen des Diffs taucht keiner dieser Fälle auf – und in einer Test-Suite, die nie einen Browser öffnet, ebenso wenig.

So fangen Sie Cursor-Bugs vor dem Merge ab

Die Verifikation muss gegen die deployte Anwendung laufen, bedient so, wie ein Mensch sie bedienen würde, und das Ergebnis muss in einer Form zurückkommen, mit der der Agent etwas anfangen kann. Sonst haben Sie den Bug zwar gefunden, beheben ihn aber weiterhin selbst.

Drei Dinge müssen erfüllt sein. Keines davon ist schwierig; fehlt eines, wird der Kreislauf undicht.

Der Agent muss wissen, wie man verifiziert

Beim Setup wird ein Verifikations-Skill direkt in den Coding-Agenten installiert, damit dieser weiß, wie er Tests erstellt, ausführt und auswertet, statt es sich aus einer README zusammenzureimen. Es schreibt eine Anweisungsdatei genau dorthin, wo Ihr Editor ohnehin danach sucht, was bedeutet, dass Cursor sie aus .cursor/rules/ liest – genauso, wie Claude Code sein eigenes Skill-Verzeichnis liest. Acht Editoren werden unterstützt, was in einem Team zählt, in dem nicht alle denselben verwenden.

Dasselbe geht über das TestSprite-Dashboard, wenn Sie lokal nichts installieren möchten. Alles Weitere, was die CLI kann, finden Sie im CLI-Repository.

Die Prüfung muss die deployte Anwendung treffen, nicht einen Mock

Richten Sie einen Lauf auf die Umgebung, in der die Änderung live ist. Der Agent öffnet die Anwendung, arbeitet das Verhalten wie ein Nutzer durch und berichtet, was tatsächlich passiert ist – nicht, ob eine Assertion in einer Sandbox erfüllt wurde. Mocks können dieses Signal nicht liefern, und genau deshalb vertragen sich eine grüne Unit-Suite und ein kaputtes Feature so gut.

Der Fehlschlag muss in einer Form zurückkommen, die der Agent verwerten kann

Hier entscheidet sich, ob sich der Kreislauf schließt. Kommt ein Fehlschlag als Screenshot in einem Dashboard an, muss ihn ein Mensch lesen, deuten und in einen Prompt übersetzen. Kommt er als ein einziges, in sich stimmiges Paket an – was versucht wurde, was die Anwendung getan hat und wo beides auseinanderging –, kann der Agent es direkt aufgreifen und damit arbeiten. Die nächste Iteration startet mit Belegen statt mit Ihrer Beschreibung der Belege.

Dafür sorgen, dass es läuft, ohne dass jemand daran denken muss

Eine Prüfung, die Sie manuell starten, ist eine Prüfung, die Sie an dem Tag überspringen, an dem es eilt – also genau dann, wenn Sie sie brauchen. Es gibt zwei Wege zur Automatisierung; welcher zu Ihnen passt, hängt davon ab, wer Ihre Pipeline verantwortet.

• Die GitHub App ist ein Webhook, den Sie im TestSprite-Dashboard einrichten. Er lauscht auf das Deployment-Event, das Ihre Pipeline ohnehin erzeugt, sodass sich in Ihrem Repository nichts ändert.

• GitHub Actions bringt den Schritt in Ihren eigenen Workflow, konfiguriert über das Terminal.

Es lohnt sich, das Modell dahinter zu verstehen, selbst wenn Sie die Konfiguration nie anfassen. Die Integration baut oder deployt Ihre Anwendung nicht, und sie legt keine Workflow-Dateien an und bearbeitet auch keine. Sie lauscht auf das Deployment-Event, das Ihre Pipeline ohnehin erzeugt, und behandelt „der neue Build ist unter dieser URL live" als Startsignal für einen Lauf. Die Ergebnisse kommen dort zurück, wo die Arbeit stattfindet: als Kommentar am Pull Request oder als Check am Commit.

Zwei Entscheidungen bestimmen, ob das Ganze nützlich ist, und beide sind Ermessenssache, keine Konfiguration.

• Welcher Moment als bereit gilt. Wählen Sie das Event, das auslöst, wenn das Deployment live ist, nicht das, welches beim Start des Builds ausgelöst wird. Ein Event, das zu früh eintrifft, richtet den Lauf auf eine URL, die noch nicht erreichbar ist – und jeder Test schlägt aus einem Grund fehl, der nichts mit Ihrem Code zu tun hat. Das ist mit Abstand der häufigste Fehler beim Einrichten.

• Ob die Prüfung beratend oder bindend ist. Ein Kommentar am Pull Request informiert. Ein erforderlicher Check blockiert den Merge. Starten Sie eine Woche lang im beratenden Modus, um zu sehen, was die Prüfung findet, und entscheiden Sie dann. Wer sie am ersten Tag verbindlich macht, bevor ihr jemand vertraut, sorgt dafür, dass eine nützliche Prüfung wieder abgeschaltet wird.

Ein praktischer Hinweis, wenn Ihre Previews auf einer Plattform wie Vercel oder Netlify liegen: Preview-URLs werden von jedem Hoster anders benannt. Die Integration nimmt deshalb ein Muster statt einer festen Adresse entgegen und setzt pro Lauf den Branch oder Pull Request ein.

Wie sich das zu Ihren bestehenden Tests verhält

Das hier ist eine Verhaltensprüfung am laufenden Produkt; sie ergänzt schnelle lokale Unit-Tests, ersetzt sie aber nicht. Behalten Sie die Unit-Tests für die Logik und lassen Sie diese Prüfung das abdecken, was jene strukturell nicht sehen können: ob das Feature funktioniert, wenn ein echter Nutzer es bedient.

Eine Anmerkung zum größeren Muster

Nichts davon ist auf Cursor beschränkt. Dieselbe Lücke entsteht bei jedem Assistenten, der Code schneller schreibt, als ein Mensch ihn lesen kann – und genau deshalb lohnt es sich, den Verifikationsschritt einmal aufzubauen und über Editoren hinweg wiederzuverwenden. In einem offenen Leaderboard, in dem Agenten dieselbe Anwendung gebaut haben, lieferte das günstigste Modell im Feld die korrekteste App, sobald dieser Verifikationskreislauf vorhanden war – zur Hälfte der Kosten des teuersten Teilnehmers. Die Lehre daraus war nicht, dass ein Modell besser ist. Sie war, dass ein Modell mit funktionierendem Feedback-Signal ein stärkeres Modell ohne ein solches schlägt.

Wo TestSprite in den Cursor-Kreislauf passt

TestSprite ist die Verifikationshälfte. Cursor schreibt die Änderung; TestSprite öffnet die deployte Anwendung, arbeitet das Verhalten so durch, wie ein Nutzer es täte, und berichtet, was tatsächlich passiert ist. Keiner der beiden versucht, die Aufgabe des anderen zu übernehmen, und genau diese Trennung ist der Punkt: Wer eine Änderung schreibt, ist die falsche Instanz, um sie zu bestätigen.

Für ein Team, das mit Cursor geschriebenen Code ausliefert, folgen daraus drei Dinge. Die Abdeckung hängt nicht mehr davon ab, ob jemand Zeit findet, Tests zu schreiben, denn die Fälle werden aus Ihrem Produkt generiert und in normaler Sprache verfeinert. Kosmetische Redesigns färben die Suite nicht mehr rot, denn ein Schritt beschreibt eine Absicht und keinen Pfad durch das DOM. Und ein Fehlschlag kommt als ein Paket zurück, mit dem der Agent arbeiten kann, sodass die nächste Iteration mit Belegen startet statt mit Ihrer Beschreibung davon.

Am ersten Tag sollten Sie damit rechnen: Die Abläufe, die zu brechen Ihnen peinlich wäre, laufen bei jedem Pull Request – mit einem Ergebnis, das die Abweichung benennt. Was es nicht tut: Ihren Code reviewen oder schnelle lokale Unit-Tests ersetzen; es arbeitet neben beidem.