Der ehrliche Ausgangspunkt
Wenn Sie den Code nicht lesen können, können Sie auch kein Code-Review machen, und Sie sollten deswegen kein schlechtes Gewissen haben. Die Alternative ist nicht das Code-Review, sondern das Prüfen des Verhaltens. Genau das tun Ihre Nutzer ohnehin, und es deckt eine Art von Problemen auf, die beim Lesen unentdeckt bliebe.
Wo Lovable-Code-Bugs meistens stecken
Generierte Apps scheitern in einer vorhersehbaren Reihenfolge. Prüfen Sie diese Punkte zuerst.
| Es sieht gespeichert aus, ist es aber nicht | Ein Formular zeigt eine Erfolgsmeldung, und nach dem Neuladen ist der Datensatz verschwunden. Laden Sie die Seite immer neu, bevor Sie einem Speichervorgang glauben. |
| Leer- und Fehlerzustände | Der Happy Path wurde gebaut und vorgeführt. Die Fälle ohne Ergebnisse und mit fehlgeschlagenen Anfragen oft nicht. Probieren Sie es ohne Daten aus, und mit einer absichtlich falschen Eingabe. |
| Der zweite Nutzer | Für das Konto, das die App gebaut hat, funktioniert alles. Berechtigungen, Eigentümerschaft und Sichtbarkeit gehen für alle anderen als Erstes kaputt. Melden Sie sich mit einem zweiten Konto an, bevor Sie die App jemandem zeigen. |
Die Prüfung, die dauerhaft funktioniert
Von Hand zu prüfen ist für ein Wochenendprojekt in Ordnung und skaliert in dem Moment nicht mehr, in dem Sie weiter prompten. Jede neue Anweisung kann stillschweigend zunichtemachen, was gestern noch funktioniert hat, und ein manueller Durchgang fällt jedes Mal kürzer aus.
Was Sie wollen: Die Prüfungen sind festgehalten und laufen automatisch, beschrieben in normaler Sprache statt in Testcode. Die Einrichtung legt diese Fähigkeit in die Hände des Agenten, sodass das Prüfen parallel zum Bauen passiert.
All das gibt es auch im TestSprite-Dashboard, was meist der bessere Weg ist, wenn Sie nicht im Terminal arbeiten. Die Details zur CLI finden Sie im CLI-Repository.
Drei Prüfungen, die sich ab Tag eins lohnen
Registrieren Sie sich, und melden Sie sich anschließend erneut an. Hier scheitern mehr generierte Apps als irgendwo sonst, und es ist das Erste, was ein echter Nutzer tut.
Legen Sie etwas an, laden Sie neu, prüfen Sie, ob es noch da ist. Diese eine Prüfung fängt den häufigsten und peinlichsten Fehler ab.
Tun Sie mit einem brandneuen Konto genau das, wofür Ihre App da ist. Wenn das für einen Fremden funktioniert, haben Sie etwas in der Hand.
So beschreiben Sie einen Bug, damit die Korrektur wirklich sitzt
Wenn etwas nicht stimmt, sagt man reflexartig „Das ist kaputt". Damit kann der Agent wenig anfangen, und Sie bekommen eine Änderung zurück, die irgendetwas daneben repariert.
Drei Sätze funktionieren deutlich besser, und für keinen davon brauchen Sie Fachvokabular. Was Sie getan haben, der Reihe nach. Was Sie erwartet haben. Was stattdessen passiert ist. „Ich habe das Formular ausgefüllt und auf Speichern geklickt, ich habe erwartet, den neuen Eintrag in der Liste zu sehen, die Liste war leer, bis ich neu geladen habe" ist ein wirklich guter Fehlerbericht, und er zeigt direkt auf den Defekt.
Dieselben drei Sätze sind zugleich die Prüfung, die Ihnen bleibt. Einmal festgehalten, lassen sie sich nach jeder künftigen Änderung erneut ausführen, und so verhindern Sie, dass dasselbe Problem wiederkommt.
Die Reihenfolge, in der Sie prüfen sollten
Es gibt eine Abfolge, die Probleme schneller findet als planloses Herumklicken, und sie dauert etwa zehn Minuten.
Beginnen Sie abgemeldet und registrieren Sie sich als völlig neuer Nutzer, denn diesen Weg sind Sie selbst am seltensten gegangen. Machen Sie dann genau das, wofür Ihre App existiert, bis zum Ende, und laden Sie die Seite neu, bevor Sie irgendetwas davon glauben. Machen Sie es anschließend absichtlich falsch: Lassen Sie ein Pflichtfeld leer, schreiben Sie Text dorthin, wo eine Zahl hingehört, laden Sie etwas Absurdes hoch. Löschen Sie danach etwas und prüfen Sie, ob es wirklich weg ist und nicht nur ausgeblendet.
Jeder dieser vier Schritte dauert ein bis zwei Minuten, und jeder trifft eine Fehlergruppe, an der generierte Apps scheitern. Die Reihenfolge ist wichtig, denn eine kaputte Registrierung macht alles Nachfolgende untestbar, und regelmäßig verbringen Leute eine Stunde mit einer Funktion, die niemand erreichen kann.
Wenn Sie so weit sind, die App zu teilen
Bevor eine App irgendwo echt zum Einsatz kommt, sollten die Prüfungen bei jeder Änderung automatisch laufen und nicht dann, wenn Sie zufällig daran denken. Dafür gibt es zwei Wege:
Verbinden Sie das Repository über das Dashboard, dann starten die Läufe aus dem Deployment, das Sie ohnehin erzeugen, oder fügen Sie stattdessen einen Schritt in Ihren eigenen Workflow ein.
Wie TestSprite das Prüfen für Sie übernimmt
Sie beschreiben in normaler Sprache, was zutreffen soll, und TestSprite übernimmt das Klicken. Kein Testcode, kein Framework, kein Terminal nötig: Legen Sie im Dashboard ein Projekt an, richten Sie es auf Ihre App und beschreiben Sie, wie eine funktionierende Version aussieht.
TestSprite deckt genau die vier Fehlergruppen dieser Seite ab. Es registriert sich als neues Konto, legt etwas an und lädt neu, um zu bestätigen, dass es gespeichert wurde, schickt etwas Ungültiges ab, um zu prüfen, ob die App das auch meldet, und durchläuft denselben Ablauf als zweiter Nutzer, um die Berechtigungsannahmen aufzudecken, die in Ihrer eigenen Sitzung stecken.
Entscheidend beim Weiterprompten ist, dass die Prüfungen bleiben. Jede Änderung wird gegen alles verifiziert, was vorher funktioniert hat, und genau das durchbricht den Kreislauf, in dem die Korrektur der einen Sache klammheimlich die nächste kaputt macht.
Muss ich dafür programmieren können?
Nein. Die Prüfungen werden in normaler Sprache beschrieben und laufen über die Oberfläche gegen die App, so wie ein Mensch sie benutzen würde.
Warum funktioniert meine App bei mir, aber nicht bei anderen?
Meistens liegt es an Berechtigungen oder an der Dateneigentümerschaft. Das Konto, das die App gebaut hat, verfügt über Datensätze und Zugriffe, die ein neues Konto nicht hat. Ein Test als zweiter Nutzer bringt das sofort ans Licht.
Soll ich vor oder nach dem nächsten Prompt testen?
Beides, und das Zweite ist wichtiger. Nur eine Prüfung, die es schon vor Ihrer letzten Anweisung gab, sagt Ihnen, ob diese Anweisung etwas kaputt gemacht hat.
Was, wenn die Korrektur immer wieder etwas anderes kaputt macht?
Das ist das Signal, die Prüfungen fortlaufend laufen zu lassen statt erst am Ende. Jede Änderung wird gegen alles verifiziert, was vorher funktioniert hat.
Gilt das nur für Lovable?
Nein. Dieselben Fehler tauchen in allem auf, was schnell generiert wurde, ganz gleich womit. Lovable-Nutzer stoßen früher darauf, weil sie früher veröffentlichen.
Sie können kein Code-Review machen. Das Verhalten können Sie prüfen.
Die meisten Lovable-Code-Bugs sind Speichervorgänge, die nicht bestehen bleiben, fehlende Leerzustände und Dinge, die nur für das Konto funktionieren, das sie gebaut hat. Prüfen Sie diese drei zuerst und automatisieren Sie die Prüfungen dann, bevor Sie die App teilen.