カーソルとクロードを使用して Playwright で自動テストを作成するパート-Python チュートリアル-php.cn

パート 1 へのリンク

パート 4

このプロジェクトの Github ソースコードリポジトリは次のとおりです: https://github.com/joegiglio/cursor2-kb

お久しぶりです…

最後に話したとき、カーソルが故障していたようで、ファイル構造のインデックスが破損していました。修正を 23 日間待った後、ようやく問題が解決されたようであることを嬉しく思います。 UI は依然として奇妙で、しばらくすると何らかのメモリリークが発生して速度が低下するようですが、再起動すると修正できます。しかし、少なくとも今では正しいファイルに変更が加えられており、ファイルインデックスが謎に破損するという事態には遭遇していません。

修正を待っている間、多くの Cursor ユーザーが Cursor や Claude の不安定性について不満を抱いていることに気づきました。はい、それは時々機能し、うまくいったときは印象的ですが、それは可動部分のブラックボックスであり、舞台裏で絶えず更新され、結果は一貫性がありません。

ヘルプデスクプロジェクトを脇に置くことにし、代わりにナレッジベースアプリケーションを構築できるかどうかを確認したいと思いました。これはもう少し簡単かもしれません。リアルタイムの更新や複雑な統合ポイントは必要ありません。

私は、Python、Flask、Bootstrap と SQLite データベースという、私が最もよく知っている同じテクノロジースタックを使用しました。すべてが順調に進んでいたのですが、「データベースの移行」で行き詰まりました。前の章と同様に、SQLite が好まない制約コードが生成され、エラーがスローされました:

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

ログイン後にコピー

クロードにとってこれは簡単に修正できるはずでしたが、問題が悪化してしまい、結局データベースを最初から再構築することになりました。これはフラスコ移行のデバッグに関する私の経験の浅さのせいにするつもりですが、クロードはデータベースを消去して最初からやり直すことなく混乱をクリーンアップすることができませんでした。

Part Using Cursor and Claude to Create Automated Tests with Playwright

物事が落ち着いた後、管理パネル、ダーク/ライトモード、検索 (SQL クエリのみを使用)、テストデータジェネレーターを備えた、ほぼ機能するナレッジベースシステムが完成しました。これは、書式設定と画像をサポートするオープンソースのテキストエディターである Quill で構築されました。

Part Using Cursor and Claude to Create Automated Tests with Playwright

「ほぼ機能している」と言ったのは、認証やマルチテナントによって意図的に複雑にしていないからです。基本的な Flask ルートと CRUD 操作を使用して、アーキテクチャをシンプルに保ちました。 API はまだありません…おそらくフェーズ 2 でこれらの機能を再検討する予定です。

私が機能を追加しているとき、クロードが本物の開発者のように、ある点を修正しても別の点を壊すことに気づきました。また、コード全体に CSS と Javascript が散在していました。新しい記事の追加は機能しても編集が機能しない場合や、その逆の場合もあります。記事の書式設定コードがあちこちに表示されることがあり、クロードにクリーンアップを依頼する必要がありました。もぐらたたきのようになってしまいました。

プロジェクトは非常に複雑になり、前の章で簡単に説明したテストの自動化が必要になりました。ほとんどの企業では、QE のための予算はほとんどなく、ほとんどの開発者はテストを書くのが嫌いです。そのため、AI が役に立つかもしれません。

私は Selenium と Cucumber についてかなりの経験がありますが、しばらく時間がかかりました。 Playwright が注目を集めており、ロケーターと再試行の処理が向上していると思われるため、Claude に Playwright テストを作成するよう依頼しました。 VS-Code Playwright 拡張機能はすべて Javascript の使用を前提としているようで、Python を直接サポートしていないため、動物のようにターミナルからテストを実行する必要があります。

Part Using Cursor and Claude to Create Automated Tests with Playwright

[プロンプト]

Playwright と Python を使用して、このプロジェクトにエンドツーエンドのブラウザテストを追加したいと考えています。テストでフィクスチャを使用して必要なデータをシードし、各テスト実行の終了時にデータを削除するようにしたいと考えています。テストはテスト自体の後にクリーンアップする必要があり、テストデータを残さないようにする必要があります。テストの実行中にテストデータベースをセットアップするように構成できれば、さらに優れています。どのライブラリをインストールするか、製品の主な機能を見て上位 10 のシナリオのテストを作成するか、Cursor 内からこれらのテストを実行する方法を教えてください。

[/プロンプト]

最初の試みは非常にうまくいき、必要なライブラリをインストールする方法についての説明が提供されました。テスト用のファイル構造も正確であるようで、ビューポートサイズを変更することによる応答性のテストも追加されました。いい感じです…しかし、私はそれが生成した最初のテストセットが気に入らなかったので、さらなる改良を求めました:

[プロンプト]

この製品にはまだ認証が実装されていません。これらの機能のテストを作成しないでください。代わりに、トピックの作成、編集、削除などの管理機能に重点を置きます。記事の追加、編集、削除。また、記事の検索や表示などのエンドユーザー機能にも重点を置きます。コードを見て製品の上位 10 個の機能を特定し、それらのテストを作成します。

[/プロンプト]

次のテストバッチは少し良くなったように見えましたが、まだ管理機能がありません。

[プロンプト]

これらのテストのほとんどは非常に良好に見えますが、@admin.html ファイルには管理機能に関するものが何も表示されません。トピックの追加、編集、削除と記事の追加、編集、削除のテストが必要です。

[/プロンプト]

これで、正しく動作し、次のアプリシナリオをテストするコードが作成されたようです。

Part Using Cursor and Claude to Create Automated Tests with Playwright

これらは素晴らしい出発点のように思えます。さあ、クロードの処刑指示が正しいかどうかを見てみましょう。残念ながらそうではありません…

[プロンプト]

指示に従ってテストを実行しましたが、いくつかの問題が発生しました。
新しいターミナルを開き、「FLASK_ENV=testing flask run」コマンドに続いて「pytest testing/e2e/」コマンドを実行しました。次の問題が発生しています:

ホームページに移動すると、前に表示されていたのと同じデータが表示されます。テストデータベースには切り替わっていないようです。

例外: conftest '/Users/joe/cursor2-kb/tests/e2e/conftest.py' のロード中に ImportError が発生しました。 testing/e2e/conftest.py:12: モデルインポートトピック、記事から ModuleNotFoundError: 'models' という名前のモジュールがありません

[/プロンプト]

クロードは models.py ファイルを作成し、app.py ファイル内のコードを複製しました。私はその理由を疑問に思いました…

このアプリケーションの最初のコードは、モデルを含めてすべて app.py ファイル内で行われました。これは正常に機能しますが、単一ファイルのアプリケーションが扱いにくくなる可能性があります。ベストプラクティスでは、モデルとルートを構成から分離するように言われています。長く曲がりくねった道をたどりましたが、ここがクロードが私を連れて行ってくれた場所です。

[プロンプト]

あなたが提案している models.py ファイルは、app.py のコードを複製しているようです。代わりに app.py のモデルを使用する方が合理的でしょうか?

[/プロンプト]

[応答]

実際には、その逆です。懸念事項の分離の原則に従うために、モデルを app.py から models.py に移動する必要があります。これは、Flask アプリケーションの一般的なパターンです。
app.py はアプリケーションの構成と初期化を処理します
models.py にはすべてのデータベースモデルが含まれています
多くの場合、ルートは別のブループリントファイルにあります

[/RESPONSE]

まあまあです。一緒に行きましょう!

まあ、それほど速くはありません。よく見てみると…

[プロンプト]

models.py ファイルを分離するところは気に入っていますが、app.py ファイルからすべてのルートも削除しています。他のファイルには見当たりません。彼らは去ってしまったばかりです…

[/プロンプト]

次に、クロードはすべてのルートを app.py ファイルから取り出し、ブループリント用の別のファイルに移動しました。アーキテクチャ上の変更が多すぎるため、元に戻してほしいのですが…すべてを書き直そうとする優秀な新しい開発者に気をつけてください! 提案された変更はプロフェッショナルな Flask コードベースのベストプラクティスと考えられていますが、テストが実施されて適切に動作していることを確認するまでは、これらの変更を信頼しません。

[プロンプト]

プロレベルの Flask コードではブループリントの使用が推奨される方法であることを理解しています。ただし、現時点ではそのようなリファクタリングを行うことに抵抗があります。私はまずエンドツーエンドのテストを実施しようとしています。次に、プロジェクトの構造を見てみましょう。ルートを app.py ファイルの外に移動しないでください。

[/プロンプト]

Part Using Cursor and Claude to Create Automated Tests with Playwright

カーソルを元に戻そうとしましたが、マージ UI は緑と赤の海であり、その変更に満足できませんでした。新しい戦略: 簡単な Playwright テストをいくつか用意して、段階的に改善していきましょう。もしかしたらこれでもっと良くなるかも…

提案されたテストリストの内容が気に入ったので、それを隠しておき、Cursor Composer ウィンドウを閉じて、新しい Composer を開始しました。これにより、以前の Composer の内容がすべて削除されたと思われます。

もっと簡単な出発点からもう一度試してみましょう。いずれにせよ、通常は反復開発が最善です。

[プロンプト]

Playwright と Python を使用して、このプロジェクトにエンドツーエンドのブラウザテストを追加したいと考えています。どのライブラリをインストールするか、製品の主な機能を見て上位 10 のシナリオのテストを作成するか、Cursor 内からこれらのテストを実行する方法を教えてください。

[/プロンプト]

今回、クロードがまだ存在しない機能をテストしたいということで、同様の問題が発生しました。クロードを叱る時間です!

[プロンプト]

認証機能のテストを作成しているようですね。ログインページがありますが、これは単なるプレースホルダーであり、実際には機能しません。誰でもログインできるようにするフィールドすらありません。プロジェクトコードをもう一度見直して、Playwright のトップ 10 のテストシナリオを考え出してください。

[/プロンプト]

これにより、クロードは謝罪し、ホームページの検索機能に関する大量のテストシナリオを作成することになりました。私は、必要なテストを手動で提供するのではなく、コードを見て機能を見つけられるようにしたいと考えていました。しかし運が悪かったので、次のようにして戻りました。

[プロンプト]

これは見た目は良くなりますが、検索に重点が置かれすぎています。次の機能のテストが必要です: 検索、トピックの作成、トピックの編集、トピックの削除、記事の作成、記事の編集、記事の削除、記事の表示、およびさまざまな画面解像度ですべてが正常に表示されることを確認するためのいくつかの応答性テスト。

[/プロンプト]

私たちはすでにスパイラルに陥り始めています…さらにいくつかのテストのための基本的なフレームワークを作成しましたが、存在するデータについてあまりにも多くの仮定を立てすぎています。仮定をしないでください。このため、事前にシードされたテストデータベースを用意することが最善ですが、最終的にはそこに到達するように努めます。今のところ…

[プロンプト]

これらのテストの一部は、特定のリンクが有効であり、特定のコンテンツが存在することを前提としています。記事やトピックが削除された場合はこの限りではありません。必要なデータを作成し、テストが完了したら削除することで、各テストを自己完結型にしてください。

[/プロンプト]

それで、クロードはとにかくフィクスチャーの作成に戻りました! 正しくやりたいのであれば、それを回避する方法はないと思います…

もう 1 つの問題は、「テスト対象」や「テスト記事」などのテスト文字列を使用することです。これは、実行を高速化するための一般的なアプローチである並列テストを実行すると衝突する可能性があります。テストでランダム化されたデータを使用したいので、次のプロンプトを表示しました:

[プロンプト]

トピック名、記事名、記事内容はランダムデータをご利用ください。外国語文字のテストを追加して、ブラウジングや検索中に外国語文字が問題なく表示されることを確認することもお勧めします。

[/プロンプト]

Part Using Cursor and Claude to Create Automated Tests with Playwright

さらに多くの調整が必要になるような気がしますが、これは非常に妥当なスタートのように見えます。クロードは次のように返しました:

次の変更が加えられました:
Faker を使用して複数の言語でランダムデータを生成します
多言語コンテンツ用の特定のテストを追加
さまざまな文字セットが適切に表示されることを確認します
非ラテン文字を使用した検索機能をテストします
表示に文字エンコードの問題がないことを確認します
複数の言語でのコンテンツ作成をテストします
テストでは、アプリケーションが以下を正しく処理できるかどうかが検証されます。
日本語 (日本語)
中国語 (中文)
韓国語 (한국어)
ロシア語 (Русский)
そして通常の英語コンテンツ
各テストは独自のランダムデータを作成し、その後クリーンアップするため、テストの信頼性と独立性が高まります。

作成されたテストは次のとおりです:

Part Using Cursor and Claude to Create Automated Tests with Playwright

さあ、実行してみましょう。まず、クロードから指示された faker ライブラリをインストールする必要があります…

テストを実行するためのさまざまなフラグとオプションがたくさん与えられました。これまでの経験から、これらの手順はすべて正しいように見えますが、クロードが作成した pytest.ini ファイルを使用し、詳細な出力、スクリーンショット、および速度を落としたテスト実行用のいくつかのフラグを渡して、従うことができるようにします。視覚的にも…

Part Using Cursor and Claude to Create Automated Tests with Playwright

そして、pytest testing/e2e/ を実行して、実際にテストを実行します。

すべてのテストが同じエラーで失敗しました:

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

ログイン後にコピー

pytest.ini では、base_url が http://localhost:5000 に設定されています。これは私にとって正しいように見えます。

なぜ失敗するのか分からなかったので、クロードに尋ねました。彼はいくつかの小さな調整を行った後、pytest.ini ファイルをプロジェクトの ROOT ディレクトリに移動し、最初に配置した test/e2e ディレクトリの外に移動することを提案しました。私がこれを押し返したところ、彼はそのままで大丈夫だと言いました。それでは…

彼はまた、INI ファイルやテキストフィクスチャに設定された URL の代わりに、テストで絶対 URL を使用することを提案しました。間違っている。私もそれを主張し、彼は同意して修正しました。ここで信仰を失います…

これらの変更を加えてテストを再度実行すると、ブラウザが開いてナレッジベースのホームページであるベース URL にアクセスできるようになりましたが、すべてのテストはまだ失敗しています。クロードとさらに数ラウンド行ったところ、ルートページの問題は修正される可能性があるように見えますが、現在は次のエラーで失敗しています:

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

ログイン後にコピー

これはロケーターの問題のようです。

[プロンプト]

test_admin.py 内のすべての管理テストが次のエラーで失敗します: admin_page.fill("#topic-title", data["title"])。それは正しいロケーターではありません。修正してください。

[/プロンプト]

クロードは 1 つのテストを修正しましたが、他のテストは依然としてロケーターエラーで失敗しています。もっと明確にしました:

[プロンプト]

test_create_topic を除いて、@test_admin.py の残りのテストはロケーターエラーで失敗します。テスト内のすべてのロケーターを確認して修正してください。

[/プロンプト]

クロードはいくつかの変更を加えましたが、今度は別のロケーターの問題が発生しました…

[プロンプト]

現在、すべてのテストが次のように失敗しています:
testing/e2e/test_admin.py::test_create_topic[chromium] - AssertionError: ロケーターが表示されることが期待されています

[/プロンプト]

私たちがしばらくここにいて、クロードが必要な修正を行っている間、ぐるぐる回ることになるのは明らかです。また、明らかで残念なことは、私がはっきりと言わなくても、Claude がアプリケーション要素とページ要素の適切なコンテキストを持っていないことです。クロードに「コードを見てテストを作成してください」と頼むだけでは十分ではありません。機能を理解できるようにするには、機能の機能とページ構造についてよく理解しておく必要があります。

Claude は、pytest.ini と conftest.py を使用したテストのアーキテクチャのセットアップに役立ちましたが、それでも、即時テストなしで基本的なテストを実行するにはいくつかの調整が必要でした。失敗。

このプロジェクトでは、JavaScript 確認およびモーダルダイアログとともにフロントエンドでブートストラップを使用します。クロードは、ソースコード内に複数のモーダルがあり、1 つだけが表示される (一般的なデザインパターンである) 場合、これらの処理に非常に苦労しているようです。数回繰り返し、疑似コードでガイドした結果、最終的には理解が深まり、テストに合格することができました。

これらのテストを通じて、クロードはロケーターの名前について多くの仮定を立てましたが、そのほとんどはソースコードのどこにも存在しませんでした。特定のファイルを調べるように明示的に指示した後でのみクリーンアップできましたが、なぜ仮定を行うのでしょうか? おそらく、最初から正しいファイルを供給しなかったのでしょうか? それがどのように機能するのかはまだわかりません。

プロジェクト全体にアクセスできるように見える場合もありますが、もっと明示的にする必要がある場合もあります。ファイルにアクセスする必要がある場合は、単にでたらめなコードを作成するのではなく、要求する必要があります。往復するたびに API クレジットがかかることに注意してください。

多くのテストの失敗に加えて、pytest.ini ファイルでフラグを渡しているにもかかわらずスクリーンショットが保存されないという問題も発生しています。クロードは私にいくつかの順列を提案してくれましたが、どれも問題を解決しませんでした。 Playwrightのドキュメントを見ましたが、まだ解決策がありません。これも「簡単に修正できるはず」な問題の 1 つのように思えますが、12 件のクロードリクエストを簡単に燃やしてしまい、すぐに解決できなくなる可能性があります。とりあえずは、クロードが提案した回避策を使用して次に進みます。

Claude との調整に非常に多くの時間を費やした結果、合格したテストは 2 つだけになり、3 つ目のテストは最初は PASS として始まりましたが、テストコードとフィクスチャコードの間の競合により最終的には FAIL になってしまいました。デバッグするのが疲れてきて、堂々巡りの会話をしているように感じます。私は、提案されたコード変更をただ盲目的にマージし、奇跡を期待するところまで来ました。

この章の前半で、私の目的は、データとテストコードをクリーンに保つために再利用可能なフィクスチャと関数とともにテストデータをシードおよび削除するテストハーネスを構築することでした。そのような意図はとうの昔に忘れ去られており、今はただテストに合格することだけを望んでおり、後でそれらをクリーンアップしようとします。何か見覚えのあるものがあれば教えてください…

起動時にブラウザウィンドウを最大化するという一見単純なように見えることでも、非常に難しいことが判明しています。クロードは Python と Javascript を試してみましたが、うまくいきませんでした。彼には理由が分からず、Stack Overflow の天才たちが何度もその質問に答えていますが、彼らの提案も機能しません。ファイル間にコードの競合があると思いますが、現時点ではそれを理解できるほどコードのことをよく知りません。 必要なときに AI はどこにあるのですか?

生成されたテストコードの一部に複数のexpect/assertが含まれていることがわかりました。私は、テストごとにアサートを 1 つだけにすることがベストプラクティスであると信じていますが、特にテストが新しく、まだ信頼していない場合には、それが常に現実的であるとは限らないことを知っておいてください。

私は、物事を正しい方向に導く方法を見つけようとしている「即席のエンジニア」であることに気づきました。私はプロダクトコードを自分で書いたことがなかったので、その内部の仕組みに詳しくなく、クロードがそれを拾って実行できることを期待していました。結局、彼はそれを書いたが、記憶が浅いようだ。彼はあなたが先に進むのに十分なものを与えてくれますが、一度尋ねてお金を集めるのに十分ではないことは確かです。

作業を容易にするのは、データの作成と削除を行う CRUD 関数を呼び出す API を用意し、エンドツーエンドのテストを目的の機能のみをテストできるようにすることです。ソフトウェアアプリケーションの自動テストを作成したことがある場合、このテストプロジェクトの欠点や欠けている機能はよく知られているように聞こえるかもしれません。 製品の機能を実際にテストする前に、製品の欠点を回避しなければならないことがよくあります。最初の章で、API ファーストの製品を構築するつもりだったが、すぐに制御不能になったことを覚えているかもしれません。 API がなければ、セットアップと破棄には直接 SQL 呼び出しを使用した方が合理的だったのかもしれません。

別のプロジェクトで自動テストを実行していて、新しいプロジェクトのコードとページ構造に精通している場合は、コピー、貼り付け、微調整を行うことで、ここで説明した Claude Playwright のアプローチよりもさらに高速に実行できる可能性があります。少なくとも、コードにある程度慣れているので、自信を持って微調整できるようになります。現時点 (2024 年 11 月) では、Playwright でエンドツーエンドテストを生成するようクロードに依頼するのは、骨の折れる作業であると感じています。

Part Using Cursor and Claude to Create Automated Tests with Playwright