Was Vibe Testing tatsächlich überflüssig macht
Es macht den Übersetzungsschritt überflüssig. Normalerweise wissen Sie, welches Verhalten Sie erwarten, und verbringen dann eine Stunde damit, es in Selektoren, Wartezeiten und Assertions zu übersetzen – wovon das meiste mit dem Framework zu tun hat und nicht mit Ihrem Produkt. Wenn Sie das Verhalten beschreiben und die Übersetzung einem Agenten überlassen, bleibt der Teil erhalten, der Bedeutung trägt, und der Teil fällt weg, der keine hat.
Das Zweite, was wegfällt, ist der Wartungsaufwand. Ein Schritt, der als Absicht formuliert ist, übersteht ein Redesign, an dem ein fest verdrahteter Selektor scheitert – denn die Absicht gilt auch dann noch, wenn der Button an eine andere Stelle rückt.
Wo eine beschriebene Prüfung schiefgeht
Zu vage, um fehlzuschlagen
„Prüfe, ob das Dashboard funktioniert“ kann nicht fehlschlagen, weil nichts Konkretes behauptet wurde.
Benennen Sie das Beobachtbare: welche Zahl, welche Zeile, welcher Zustand.
Die Aktion als Prüfung behandeln
„Auf Speichern klicken“ ist ein Schritt, keine Prüfung. Ein Durchlauf kann ihn ausführen und beweist damit nichts.
Sagen Sie, was danach zutreffen soll – und zwar etwas, das ein Neuladen bestätigen würde.
Unklares Subjekt
„Der Nutzer sieht seine Bestellungen“ lässt offen, welcher Nutzer gemeint ist, und genau dort stecken Berechtigungsfehler.
Sagen Sie, wessen Bestellungen – und prüfen Sie, dass jemand anderes sie nicht sehen kann.
Die eine Gewohnheit, die echte Prüfungen von dekorativen trennt
Machen Sie die Sache absichtlich kaputt und vergewissern Sie sich, dass die Prüfung rot wird. Das dauert eine Minute und ist der einzige Beleg dafür, dass die Prüfung überhaupt mit etwas verbunden ist.
Hier zählt das mehr als bei handgeschriebenen Tests, weil eine beschriebene Prüfung mehr Spielraum für großzügige Auslegung lässt. Ein Durchlauf, der endet, ohne je eine Assertion zu erreichen, ist kein bestandener Test – und der einzige Weg herauszufinden, dass Sie so einen haben, ist der Versuch, ihn zum Fehlschlagen zu bringen.
Erste Schritte
Die Einrichtung installiert die Funktion im Coding-Agenten, sodass Prüfungen dort beschrieben und ausgeführt werden können, wo auch der Code entsteht.
Nichts davon braucht ein Terminal. Legen Sie im TestSprite-Dashboard ein Projekt an, beschreiben Sie die Prüfung in normaler Sprache und richten Sie sie auf Ihre App. Entwickler in Ihrem Team können dasselbe über die Kommandozeile steuern, wenn ihnen das lieber ist – zu finden im CLI-Repository.
Was Sie zuerst beschreiben sollten
Der Ablauf, den Sie vorführen würden. Wenn er kaputtgeht, erfahren Sie es vor Publikum – deshalb sollte er als Erstes abgedeckt sein.
Alles, was mit Geld oder Berechtigungen zu tun hat. Die höchsten Kosten im Fehlerfall, und beides scheitert lautlos.
Das, was zuletzt kaputtgegangen ist. Was Sie einmal kalt erwischt hat, ist eine dauerhafte Prüfung wert, und Sie wissen bereits genau, wie Sie sie beschreiben.
Eine Prüfung beschreiben, die hält
Der Unterschied zwischen einer Prüfung, die Sie schützt, und einer, die nur die Pipeline schmückt, liegt fast immer darin, wie sie beschrieben wurde – und dieses Muster lässt sich lernen.
Eine gute Beschreibung besteht aus drei Teilen: einem Ausgangszustand, einer Aktion und etwas Beobachtbarem danach, das ein Neuladen bestätigen würde. „Als angemeldeter Nutzer ohne gespeicherte Filter einen Filter namens Recent anlegen, neu laden und bestätigen, dass er in der Seitenleiste erscheint.“ Jeder dieser Teile kann fehlschlagen, und der Fehlschlag sagt Ihnen, wo.
Vergleichen Sie das mit „prüfen, ob Filter funktionieren“. Dieselbe Absicht, aber kein Ausgangszustand, keine konkrete Aktion, nichts Beobachtbares. Ein Agent, der das erfüllen soll, wird irgendetwas Plausibles tun und Erfolg melden, und Sie haben nichts gelernt. Die fünfzehn Sekunden mehr, die in die erste Variante fließen, machen den ganzen Unterschied.
Hören Sie dann auf, jedes Mal zu entscheiden, wann sie laufen
Ob beschrieben oder programmiert: Eine Prüfung, die auf einen Menschen wartet, ist eine Prüfung, die in einer vollen Woche übersprungen wird.
Verbinden Sie das Repository im Dashboard, dann starten die Durchläufe aus dem Deployment, das Sie ohnehin erzeugen – oder fügen Sie stattdessen einen Schritt in Ihren eigenen Workflow ein.
Was TestSprite mit einer beschriebenen Prüfung macht
Sie sagen, was zutreffen soll; TestSprite ermittelt, wie sich das prüfen lässt, und führt die Prüfung gegen Ihre deployte App aus. Der Übersetzungsschritt, der Teil, um den es nie ging, fällt weg.
Zwei Eigenschaften machen das Ergebnis haltbar. Schritte werden als Absichten gespeichert und nicht als Pfade durch das DOM, sodass ein Redesign, das einen Button verschiebt, die Prüfung nicht zerstört. Und das Ergebnis kommt als Beschreibung zurück: was versucht wurde, was passiert ist und wo beides auseinanderging. Genau das erlaubt es einem Coding-Agenten, auf einen Fehlschlag zu reagieren, ohne dass ihn vorher ein Mensch interpretieren muss.
Auch das Nachschärfen bleibt in normaler Sprache. Ist eine Prüfung zu locker, sagen Sie das in einem Satz, statt Code zu bearbeiten – und genau deshalb lohnen sich beschriebene Prüfungen überhaupt.
Ist Vibe Testing zuverlässig genug für ein echtes Produkt?
Für die verhaltensbezogene Abdeckung von Abläufen: ja, vorausgesetzt, jede Prüfung benennt etwas Konkretes und Sie haben bestätigt, dass sie fehlschlagen kann. Für Assertions auf exakte Reihenfolgen oder auf Komponentenebene sind geschriebene Tests weiterhin das bessere Werkzeug.
Worin unterscheidet sich das von einer aufgezeichneten Klickstrecke?
Eine Aufzeichnung hält einen Pfad fest und geht kaputt, sobald sich der Pfad ändert. Eine beschriebene Prüfung hält eine Absicht fest und übersteht die Änderung – darin liegt der größte Teil des Wartungsunterschieds.
Was ist, wenn der Agent meine Beschreibung anders auslegt?
Lesen Sie die generierten Schritte einmal durch, bevor Sie der Prüfung vertrauen. Dort fallen Fehlinterpretationen sofort auf und sind später in einem bestandenen Ergebnis viel schwerer zu erkennen.
Kann ich eine Prüfung nachschärfen, ohne sie neu zu schreiben?
Ja. Passen Sie sie in normaler Sprache an, genauso, wie Sie sie ursprünglich beschrieben haben.
Ersetzt das Unit-Tests?
Nein. Unit-Tests sind schneller und bei Logik besser. Das hier deckt die Ebene ab, die sie nicht sehen können: ob sich das zusammengesetzte Produkt korrekt verhält.
Beschreiben Sie etwas Konkretes und bringen Sie es dann einmal zum Fehlschlagen.
Vibe Testing beseitigt die Übersetzung von der Absicht in Testcode, also den Teil, um den es nie ging. Benennen Sie etwas Konkretes und Beobachtbares, bestätigen Sie, dass die Prüfung rot werden kann, und lassen Sie sie automatisch laufen, statt jedes Mal neu zu entscheiden.