Teil: Verwendung von Cursor und Claude zum Erstellen automatisierter Tests mit Playwright

Link zu Teil 1

TEIL 4

Hier ist das Github-Quellcode-Repo für dieses Projekt: https://github.com/joegiglio/cursor2-kb

Es ist schon eine Weile her…

Als wir das letzte Mal gesprochen haben, schien der Cursor kaputt zu sein und der Index der Dateistruktur war beschädigt. Nachdem ich 23 Tage auf eine Lösung gewartet habe, freue ich mich, Ihnen mitteilen zu können, dass das Problem endlich behoben zu sein scheint! Die Benutzeroberfläche ist immer noch eigenartig und scheint nach einer Weile langsamer zu werden, da es zu einem Speicherverlust kommt, der durch einen Neustart behoben werden kann. Aber immerhin werden jetzt Änderungen an den richtigen Dateien vorgenommen und ich bin nicht mit einem auf mysteriöse Weise beschädigten Dateiindex konfrontiert.

Während ich auf eine Lösung wartete, bemerkte ich, dass sich viele Cursor-Benutzer über die Instabilität von Cursor und/oder Claude beschwerten. Ja, es funktioniert manchmal und es ist beeindruckend, wenn es funktioniert, aber es ist eine Blackbox aus beweglichen Teilen, ständigen Aktualisierungen hinter den Kulissen und inkonsistenten Ergebnissen.

Ich habe beschlossen, das Helpdesk-Projekt beiseite zu legen und wollte sehen, ob ich stattdessen eine Wissensdatenbank-Anwendung erstellen kann. Dies könnte etwas einfacher sein – es sind keine Echtzeit-Updates oder komplexe Integrationspunkte erforderlich.

Ich habe denselben Technologie-Stack verwendet, mit dem ich am besten vertraut bin – Python, Flask und Bootstrap mit einer SQLite-Datenbank. Alles lief reibungslos, bis ich bei „Datenbankmigrationen“ auf ein Problem stieß. Ähnlich wie im vorherigen Kapitel wurde ein Einschränkungscode generiert, der SQLite nicht gefiel, und es wurde ein Fehler ausgegeben:

Exception during DB migration:
 raise ValueError("Constraint must have a name")
ValueError: Constraint must have a name

Das hätte für Claude leicht zu beheben sein, aber es begann sich zu verschlechtern und am Ende baute ich meine Datenbank von Grund auf neu auf. Ich gebe dafür meiner Unerfahrenheit beim Debuggen von flask-migrate die Schuld, aber Claude war nicht in der Lage, das Chaos zu beseitigen, ohne einfach die Datenbank zu löschen und von vorne zu beginnen.

Nachdem sich die Dinge beruhigt hatten, hatte ich ein größtenteils funktionierendes Wissensdatenbanksystem, zusammen mit einem Admin-Panel, einem Dunkel-/Hellmodus, einer Suche (nur mithilfe der SQL-Abfragen) und einem Testdatengenerator. Es wurde mit Quill erstellt, einem Open-Source-Texteditor mit Unterstützung für Formatierung und Bilder.

Ich sage „größtenteils funktionsfähig“, weil ich es absichtlich nicht durch Authentifizierung oder Mehrmandantenfähigkeit verkompliziert habe. Ich habe die Architektur mit grundlegenden Flask-Routen und CRUD-Operationen einfach gehalten. Noch keine API … Vielleicht werde ich diese Funktionen in Phase 2 noch einmal aufgreifen.

Während ich Funktionen hinzufügte, fiel mir immer wieder auf, dass Claude eine Sache reparierte, eine andere jedoch kaputt machte – genau wie ein echter Entwickler. Außerdem waren überall im Code CSS und Javascript verstreut. Manchmal funktionierte das Hinzufügen neuer Artikel, das Bearbeiten jedoch nicht und umgekehrt. Manchmal tauchte hier und da Artikelformatierungscode auf und ich musste Claude bitten, ihn zu bereinigen. Es wurde immer heftiger.

Das Projekt wurde so komplex, dass eine Testautomatisierung erforderlich war, die im letzten Kapitel kurz besprochen wurde. In den meisten Unternehmen gibt es nur sehr wenig Budget für QE und die meisten Entwickler hassen es, Tests zu schreiben, also kann KI vielleicht helfen?

Ich habe ziemlich viel Erfahrung mit Selen und Gurke, aber es ist schon eine Weile her. Playwright erfreut sich zunehmender Beliebtheit und verfügt angeblich über ein besseres Handling für Locators und Wiederholungsversuche. Deshalb habe ich Claude gebeten, einige Playwright-Tests zu erstellen. Die VS-Code Playwright-Erweiterungen scheinen alle davon auszugehen, dass Sie Javascript verwenden, und sie bieten keine direkte Unterstützung für Python, sodass ich die Tests wie ein Tier vom Terminal aus ausführen muss.

[PROMPT]

Ich möchte diesem Projekt End-to-End-Browsertests mit Playwright und Python hinzufügen. Ich möchte, dass die Tests Vorrichtungen verwenden, um die erforderlichen Daten zu ermitteln und die Daten dann am Ende jedes Testlaufs zu löschen. Die Tests müssen sich selbst bereinigen und dürfen keine Testdaten zurücklassen. Wenn Sie es so konfigurieren können, dass während der Ausführung der Tests eine Testdatenbank eingerichtet wird, ist das sogar noch besser. Bitte teilen Sie mir mit, welche Bibliotheken installiert werden sollen, erstellen Sie Tests für die Top-10-Szenarien, indem Sie sich die Hauptfunktionen des Produkts ansehen, und teilen Sie mir mit, wie diese Tests in Cursor ausgeführt werden.

[/PROMPT]

Der erste Versuch war ziemlich gut und enthielt Anweisungen zur Installation der erforderlichen Bibliotheken. Die Dateistruktur für die Tests schien ebenfalls korrekt zu sein und es wurde sogar ein Test zur Reaktionsfähigkeit hinzugefügt, indem die Größe des Ansichtsfensters geändert wurde. Nette Geste… Aber mir gefielen die anfänglichen Tests, die es generierte, nicht, also habe ich um weitere Verfeinerung gebeten:

[PROMPT]

Authentifizierung wurde in diesem Produkt noch nicht implementiert. Bitte erstellen Sie keine Tests für diese Funktionen. Konzentrieren Sie sich stattdessen auf Admin-Funktionen wie das Erstellen, Bearbeiten und Löschen von Themen. Artikel hinzufügen, bearbeiten und löschen. Konzentrieren Sie sich außerdem auf Endbenutzerfunktionen wie das Suchen und Anzeigen von Artikeln. Schauen Sie sich den Code an, um die zehn wichtigsten Funktionen des Produkts herauszufinden und Tests dafür zu erstellen.

[/PROMPT]

Die nächsten Tests sahen etwas besser aus, aber immer noch keine Admin-Funktionalität.

[PROMPT]

Die meisten dieser Tests sehen ziemlich gut aus, aber ich sehe in der Datei @admin.html nichts für die Admin-Funktionalität. Wir benötigen Tests zum Hinzufügen, Bearbeiten und Löschen von Themen sowie zum Hinzufügen, Bearbeiten und Löschen von Artikeln.

[/PROMPT]

Jetzt sieht es so aus, als hätte es alles richtig gemacht und Code erstellt, um die folgenden App-Szenarien zu testen:

Das scheinen großartige Ausgangspunkte zu sein. Nun wollen wir sehen, ob die Ausführungsanweisungen von Claude korrekt sind. Naja, leider nicht…

[PROMPT]

Ich habe Ihre Anweisungen zur Durchführung der Tests befolgt und stoße auf ein paar Probleme.
Ich habe ein neues Terminal geöffnet und die Befehle „FLASK_ENV=testing flask run“ gefolgt von „pytest tests/e2e/“ ausgeführt. Ich sehe folgende Probleme:

1. Wenn ich zur Startseite navigiere, sehe ich dieselben Daten wie zuvor. Es schien nicht zur Testdatenbank zu wechseln.
2. Eine Ausnahme: ImportError beim Laden von conftest '/Users/joe/cursor2-kb/tests/e2e/conftest.py'. tests/e2e/conftest.py:12: in from models import Topic, Article ModuleNotFoundError: Kein Modul mit dem Namen „models“

[/PROMPT]

Claude hat eine models.py-Datei erstellt und den Code in der app.py-Datei dupliziert, und ich habe mich gefragt, warum...

Der ursprüngliche Code für diese Anwendung wurde vollständig in der Datei app.py erstellt, einschließlich der Modelle. Das funktioniert gut, kann jedoch dazu führen, dass Sie eine unhandliche Einzeldateianwendung erhalten. Best Practice besagt, die Modelle und Routen von der Konfiguration zu trennen, und genau hier hat mich Claude hingeführt, auch wenn es ein langwieriger Weg war:

[PROMPT]

Die von Ihnen vorgeschlagene Datei models.py sieht so aus, als würde sie Code von app.py duplizieren. Wäre es sinnvoller, stattdessen die Modelle in app.py zu verwenden?

[/PROMPT]

[ANTWORT]

Eigentlich ist es umgekehrt – wir sollten die Modelle aus app.py nach models.py verschieben, um dem Prinzip der Trennung von Belangen zu folgen. Dies ist ein häufiges Muster in Flask-Anwendungen, bei denen:
app.py übernimmt die Anwendungskonfiguration und -initialisierung
models.py enthält alle Datenbankmodelle
Routen befinden sich oft in separaten Blueprint-Dateien

[/ANTWORT]

In Ordnung. Lasst uns weitermachen!

Na ja, nicht so schnell. Bei näherer Betrachtung…

[PROMPT]

Mir gefällt, was Sie mit der Trennung der models.py-Datei erreichen, aber Sie haben auch alle Routen aus der app.py-Datei gelöscht. Ich sehe sie in keiner anderen Datei. Sie sind einfach weg…

[/PROMPT]

Jetzt hat Claude alle Routen aus der Datei app.py gezogen und sie in eine separate Datei für Blaupausen verschoben. Es werden viel zu viele architektonische Änderungen vorgenommen, und ich möchte, dass dies rückgängig gemacht wird ... Hüten Sie sich vor dem brillanten neuen Entwickler, der alles neu schreiben möchte! Obwohl die vorgeschlagenen Änderungen als Best Practices für eine professionelle Flask-Codebasis gelten, vertraue ich diesen Änderungen erst, wenn die Tests durchgeführt wurden, damit wir überprüfen können, ob sie ordnungsgemäß funktionieren.

[PROMPT]

Mir ist bewusst, dass die Verwendung von Blaupausen die bevorzugte Methode für Flask-Code auf professionellem Niveau ist. Allerdings fühle ich mich derzeit nicht wohl dabei, solche Refaktoren durchzuführen. Ich versuche zunächst, umfassende Tests durchzuführen. Dann können wir uns die Projektstruktur ansehen. Bitte verschieben Sie die Routen nicht aus der app.py-Datei.

[/PROMPT]

Der Cursor hat versucht, zurückzukehren, aber die Zusammenführungsoberfläche war ein Meer aus Grün und Rot und ich war mit der Änderung nicht zufrieden. Neue Strategie: Lassen Sie uns einige einfache Playwright-Tests durchführen und dann daran arbeiten, sie schrittweise zu verbessern. Vielleicht ist das besser...

Ich habe die vorgeschlagene Testliste verstaut, da mir gefiel, wo sie hinführte, und dann das Cursor-Composer-Fenster geschlossen und einen neuen Composer gestartet, der meiner Meinung nach den gesamten Inhalt des vorherigen Composers entfernt.

Versuchen wir es noch einmal mit einem einfacheren Ausgangspunkt. Eine iterative Entwicklung ist in der Regel ohnehin am besten.

[PROMPT]

Ich möchte diesem Projekt End-to-End-Browsertests mit Playwright und Python hinzufügen. Bitte teilen Sie mir mit, welche Bibliotheken installiert werden sollen, erstellen Sie Tests für die Top-10-Szenarien, indem Sie sich die Hauptfunktionen des Produkts ansehen, und teilen Sie mir mit, wie diese Tests in Cursor ausgeführt werden.

[/PROMPT]

Wir hatten dieses Mal ähnliche Probleme, als Claude Funktionen testen wollte, die es noch nicht gibt. Zeit, Claude zu schelten!

[PROMPT]

Wie ich sehe, erstellen Sie Tests für die Authentifizierungsfunktionalität. Obwohl wir eine Anmeldeseite haben, ist diese nur ein Platzhalter und funktioniert nicht wirklich. Es gibt nicht einmal Felder, die es jedem ermöglichen, sich anzumelden. Bitte überprüfen Sie den Projektcode noch einmal und ermitteln Sie die zehn besten Testszenarien für Playwright.

[/PROMPT]

Dies veranlasste Claude dazu, sich zu entschuldigen und eine Reihe von Testszenarien rund um die Suchfunktion auf der Startseite zu erstellen. Ich hatte gehofft, die Tests, die ich wollte, nicht manuell einzugeben, sondern wollte stattdessen, dass die Funktionen durch einen Blick auf den Code gefunden werden. Allerdings ohne Erfolg, also ging ich zurück mit:

[PROMPT]

Das sieht besser aus, ist aber zu sehr auf die Suche ausgerichtet. Wir benötigen Tests für die folgenden Funktionen: Suchen, Thema erstellen, Thema bearbeiten, Themen löschen, Artikel erstellen, Artikel bearbeiten, Artikel löschen, Artikel anzeigen und einige Reaktionstests, um sicherzustellen, dass auf verschiedenen Bildschirmauflösungen alles in Ordnung aussieht.

[/PROMPT]

Wir geraten bereits in eine Spirale ... Es wurde das Grundgerüst für weitere Tests geschaffen, aber es werden zu viele Annahmen über die Daten getroffen, die existieren werden. Machen Sie keine Annahmen. Aus diesem Grund ist es am besten, eine Testdatenbank zu haben, die bereits vorinstalliert ist, aber wir werden versuchen, irgendwann dorthin zu gelangen. Vorerst…

[PROMPT]

Einige dieser Tests gehen davon aus, dass bestimmte Links gültig sind und bestimmte Inhalte vorhanden sind. Dies ist möglicherweise nicht der Fall, wenn Artikel oder Themen gelöscht werden. Bitte machen Sie jeden Test eigenständig, indem Sie die benötigten Daten erstellen und sie dann löschen, wenn der Test abgeschlossen ist.

[/PROMPT]

Jetzt ist Claude also sowieso wieder dabei, Vorrichtungen zu erstellen! Ich denke, daran führt kein Weg vorbei, wenn man es richtig machen will …

Ein weiteres Problem ist die Verwendung von Testzeichenfolgen wie „Testsubjekt“ und „Testartikel“, die möglicherweise in Konflikt geraten, wenn wir parallele Tests ausführen, was ein gängiger Ansatz zur Beschleunigung der Ausführung ist. Ich wollte, dass die Tests randomisierte Daten verwenden, also habe ich Folgendes dazu aufgefordert:

[PROMPT]

Bitte verwenden Sie Zufallsdaten für den Themennamen, den Artikelnamen und den Artikelinhalt. Es wäre auch eine gute Idee, einen Test für fremdsprachige Zeichen hinzuzufügen, um sicherzustellen, dass sie beim Surfen und Suchen in Ordnung angezeigt werden.

[/PROMPT]

Ich habe das Gefühl, dass wir noch viel mehr Optimierungen brauchen werden, aber das sieht nach einem sehr vernünftigen Anfang aus. Claude hat Folgendes zurückgegeben:

Diese Änderungen wurden vorgenommen:
Verwenden Sie Faker, um Zufallsdaten in mehreren Sprachen zu generieren
Fügen Sie spezifische Tests für mehrsprachige Inhalte hinzu
Überprüfen Sie die korrekte Anzeige verschiedener Zeichensätze
Testen Sie die Suchfunktion mit nicht-lateinischen Zeichen
Stellen Sie sicher, dass bei der Anzeige keine Probleme mit der Zeichenkodierung vorliegen
Testen Sie die Inhaltserstellung in mehreren Sprachen
Die Tests überprüfen nun, ob Ihre Anwendung Folgendes korrekt verarbeitet:
Japanisch (日本語)
Chinesisch (中文)
Koreanisch (한국어)
Russisch (Русский)
Und regelmäßige englische Inhalte
Jeder Test erstellt seine eigenen Zufallsdaten und bereinigt sie selbst, wodurch die Tests zuverlässiger und unabhängiger werden.

Dies sind die Tests, die erstellt wurden:

Jetzt führe ich sie aus. Zuerst muss ich die faker-Bibliothek installieren, wozu Claude mich angewiesen hat …

Mir wurden eine Reihe verschiedener Flags und Optionen zum Ausführen der Tests angezeigt. Aus früheren Erfahrungen sehen alle diese Anweisungen richtig aus, aber ich werde die von Claude erstellte Datei pytest.ini verwenden und ein paar Flags für eine ausführliche Ausgabe, Screenshots und eine verlangsamte Testausführung übergeben, damit ich folgen kann optisch entlang…

Und jetzt müssen Sie pytest tests/e2e/ ausführen, um die Tests tatsächlich auszuführen!

Alle Tests sind mit demselben Fehler fehlgeschlagen:

Exception during DB migration:
 raise ValueError("Constraint must have a name")
ValueError: Constraint must have a name

In pytest.ini ist die base_url auf http://localhost:5000 gesetzt, was für mich richtig aussieht.

Ich konnte nicht herausfinden, warum es fehlschlug, also fragte ich Claude. Er nahm ein paar kleine Änderungen vor und schlug mir dann vor, die Datei pytest.ini in das ROOT-Verzeichnis des Projekts und aus dem Verzeichnis tests/e2e zu verschieben, in dem er sie ursprünglich abgelegt hatte. Ich habe das zurückgewiesen und er sagte, es sei in Ordnung, wo es ist. Okay, dann...

Er schlug außerdem vor, dass ich in den Tests absolute URLs anstelle der in der INI-Datei und den Text-Fixtures festgelegten URLs verwende. Falsch. Ich habe das auch zurückgedrängt und er hat zugestimmt und das Problem behoben. Hier verliere ich den Glauben…

Mit diesen Änderungen habe ich die Tests erneut ausgeführt und jetzt sehe ich, wie sich der Browser öffnet und zur Basis-URL wechselt, die die Homepage der Wissensdatenbank darstellt, aber alle Tests schlagen immer noch fehl. Ich habe noch ein paar Runden mit Claude verbracht und es sieht so aus, als ob die Probleme mit der Root-Seite behoben sein könnten, aber jetzt scheitern wir mit:

playwright._impl._errors.Error: Protocol error (Page.navigate): Cannot navigate to invalid URL

Was eher nach einem Ortungsproblem aussieht.

[PROMPT]

Jetzt schlagen alle Admin-Tests in test_admin.py mit diesem Fehler fehl: admin_page.fill("#topic-title", data["title"]). Das ist nicht der richtige Locator. Bitte beheben.

[/PROMPT]

Claude hat einen Test behoben, aber die anderen schlagen immer noch mit Locator-Fehlern fehl. Ich wurde expliziter:

[PROMPT]

Mit Ausnahme von test_create_topic schlagen die restlichen Tests in @test_admin.py mit Locator-Fehlern fehl. Bitte überprüfen Sie alle Locators in den Tests und korrigieren Sie sie.

[/PROMPT]

Claude hat ein paar Änderungen vorgenommen und jetzt haben wir ein weiteres Problem mit dem Ortungsgerät …

[PROMPT]

Jetzt schlagen alle Tests fehl mit:
tests/e2e/test_admin.py::test_create_topic[chromium] – AssertionError: Es wird erwartet, dass der Locator sichtbar ist

[/PROMPT]

Es ist klar, dass wir noch eine Weile hier bleiben und herumlaufen werden, während Claude die notwendigen Korrekturen vornimmt. Was auch offensichtlich und bedauerlich ist, ist, dass Claude nicht über den richtigen Kontext der Anwendungs- und Seitenelemente verfügt, ohne dass ich es sehr deutlich sagen muss. Es reicht nicht aus, Claude einfach zu bitten, „sich den Code anzusehen und Tests zu erstellen“. Sie müssen mit der Funktionalität der Features und der Seitenstruktur bestens vertraut sein, damit Sie sie pflegen können.

Claude war hilfreich beim Einrichten der Testarchitektur mit pytest.ini und conftest.py, aber dennoch waren mehrere Anpassungen erforderlich, damit ein Basistest ohne Soforttest ausgeführt werden konnte Versagen.

Dieses Projekt verwendet Bootstrap im Frontend zusammen mit Javascript-Bestätigung und modalen Dialogen. Claude scheint damit große Schwierigkeiten zu haben, wenn der Quellcode mehrere Modalitäten enthält, von denen nur eine sichtbar ist, was ein gängiges Designmuster ist. Nach mehreren Iterationen und der Anleitung mit Pseudocode kamen wir schließlich zu einem Verständnis und bestanden den Test.

Während dieser Tests machte Claude viele Annahmen über die Namen der Locators, von denen die meisten nirgendwo im Quellcode existierten. Erst nachdem es ausdrücklich angewiesen wurde, in bestimmten Dateien nachzusehen, konnte es bereinigen, aber warum Annahmen treffen? Vielleicht habe ich ihm von Anfang an nicht die richtigen Dateien zugeführt? Ich bin mir immer noch nicht sicher, wie das alles funktionieren soll.

Manchmal scheint es Zugriff auf das gesamte Projekt zu haben, während ich manchmal viel expliziter sein muss. Wenn es Zugriff auf eine Datei benötigt, sollte es danach fragen und nicht einfach nur Bullshit-Code erstellen. Denken Sie daran, dass jedes Hin und Her API-Credits kostet.

Neben vielen Testfehlern habe ich auch Probleme damit, dass Screenshots nicht gespeichert werden, obwohl ich das Flag in der Datei pytest.ini übergebe. Claude bot mir ein paar Permutationen an, aber keine davon löste das Problem. Ich habe mir die Playwright-Dokumentation angesehen und immer noch keine Lösung gefunden. Dies scheint ein weiteres dieser Probleme zu sein, die „leicht zu beheben sein sollten“, aber Sie können leicht ein Dutzend Claude-Anfragen verbrennen und schnell nichts erreichen. Ich werde vorerst weitermachen und eine von Claude vorgeschlagene Problemumgehung verwenden.

Nachdem ich VIEL ZU viel Zeit damit verbracht habe, mit Claude Optimierungen vorzunehmen, habe ich jetzt nur noch zwei Tests, die bestanden wurden, und einen dritten, der mit PASS beginnt, aber letztendlich aufgrund eines Konflikts zwischen dem Testcode und dem Vorrichtungscode als FAIL endet. Das Debuggen wird immer anstrengender und ich habe das Gefühl, dass ich zyklische Gespräche führe. Ich bin an einem Punkt angelangt, an dem ich die vorgeschlagenen Codeänderungen einfach blind zusammenführe und auf ein Wunder hoffe.

Zu Beginn dieses Kapitels hatte ich die Absicht, eine Testumgebung zu erstellen, die Testdaten zusammen mit wiederverwendbaren Vorrichtungen und Funktionen auswertet und entfernt, um die Daten und den Testcode sauber zu halten. Diese Absichten sind längst aus dem Blickfeld geraten und jetzt möchte ich nur noch, dass die Tests bestehen und ich werde später versuchen, sie zu bereinigen. Lassen Sie mich wissen, wenn Ihnen etwas davon bekannt vorkommt …

Selbst etwas scheinbar Einfaches wie das Maximieren des Browserfensters beim Start erweist sich als viel zu schwierig. Claude hat Versuche mit Python und Javascript gemacht und es funktioniert einfach nicht. Er weiß nicht warum, und die Genies von Stack Overflow haben diese Frage mehrmals beantwortet, und auch ihre Vorschläge funktionieren nicht. Ich vermute, dass es einen Codekonflikt zwischen den Dateien gibt, aber ich kenne den Code nicht gut genug, um ihn im Moment herauszufinden. Wo ist KI, wenn Sie sie brauchen!?

Ich habe festgestellt, dass einige der generierten Testcodes mehr als ein Expect/Assert hatten. Ich halte es für die beste Praxis, nur EINE Behauptung pro Test zu haben, aber ich weiß, dass dies nicht immer realistisch ist, insbesondere wenn die Tests neu sind und man ihnen noch nicht vertraut.

Ich fühlte mich wie ein „schneller Ingenieur“, der versuchte herauszufinden, wie man die Dinge in die richtige Richtung lenkt. Da ich den Produktcode nicht selbst geschrieben habe, war ich mit seinem Innenleben nicht vertraut und hoffte, dass Claude es in die Hand nehmen und damit arbeiten könnte. Immerhin hat er es geschrieben, aber er scheint ein kurzes Gedächtnis zu haben. Er gibt Ihnen genug, um loszulegen, aber sicherlich nicht genug, um einmal zu fragen und das Geld einzusammeln.

Was das Leben einfacher machen würde, wären APIs zum Aufrufen von CRUD-Funktionen, die Daten erstellen und löschen, so dass die End-to-End-Tests nur die beabsichtigte Funktionalität testen würden. Wenn Sie jemals automatisierte Tests für eine Softwareanwendung geschrieben haben, kommen Ihnen die Mängel und fehlenden Funktionen dieses Testprojekts vielleicht nur allzu bekannt vor. Am Ende müssen Sie häufig Produktmängel beheben, bevor Sie tatsächlich mit dem Testen der Produktfunktionalität beginnen. Sie erinnern sich vielleicht noch an das erste Kapitel, als ich vorhatte, das Produkt API-First zu entwickeln, und das geriet schnell außer Kontrolle. Ohne APIs wären direkte SQL-Aufrufe für den Auf- und Abbau möglicherweise sinnvoller gewesen.

Wenn Sie automatisierte Tests in einem anderen Projekt haben und mit dem Code und der Seitenstruktur eines neuen Projekts vertraut sind, kommen Sie mit Kopieren/Einfügen/Optimieren wahrscheinlich schneller weiter als mit dem hier beschriebenen Claude Playwright-Ansatz. Zumindest sind Sie dann mit dem Code einigermaßen vertraut und können ihn mit einiger Sicherheit anpassen. Zum jetzigen Zeitpunkt (November 2024) empfinde ich es als schmerzhafte Übung, Claude zu bitten, End-to-End-Tests mit Playwright zu erstellen.

ÜBER DEN AUTOR

Joe Giglio ist seit 25 Jahren in der Softwarebranche tätig. Im Laufe seiner Karriere hat er für einen lokalen Einwahl-ISP, Start-ups jeder Größe und ein gut etabliertes, langsam wachsendes Unternehmen gearbeitet. Bei jedem Stopp wurden wichtige Erkenntnisse gewonnen.

Zu seinen jüngsten Projekten gehören:

Training und Beratung für Fernarbeit: Chiefremoteofficer.com

Kindle-Buch „Making Remote Work, Work For You“

Remote-Unternehmensrankings. Denken Sie an „Glassdoor für Remote-Unternehmen“: remotescorecard.com

Joes Leitprinzipien sind: Remote First, Qualitätsorientierung, Kundenverfechter und lebenslanges Lernen. Er war introvertiert und übte soziale Distanzierung, lange bevor es cool war!

Er lebt derzeit in North Carolina und ist immer an neuen Möglichkeiten interessiert, qualifizierte Leute kennenzulernen und spannende Projekte kennenzulernen.

Kontaktieren Sie Joe Giglio: joe -AT- joegiglio.org | Twitter | LinkedIn

Das obige ist der detaillierte Inhalt vonTeil: Verwendung von Cursor und Claude zum Erstellen automatisierter Tests mit Playwright. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!