はじめに

AI技術の進展は目覚ましく、もはや何が起こっているのか追いつけなくなってきた。
自分で調べるのが面倒くさいし、調べてもよくわからないことが多いので、Youtube等を垂れ流しながらフムフムとすることが多い。
年末年始にフムフムしていたら、WindsurfというVSCodeベースのAIエディタがリリースされていたので、少し触ってみた。

何をしたか

自動テストをPlaywrightで書きたいが、当方はPlaywrightに詳しくないのでAIに助けてもらった。
ついでに、自然言語で記述された自動テストシナリオをPlaywrightコード化することの実現可能性 を少し想像した。

なお、Playwright/Javaである。

WindsurfにPlaywrightコードを書いてもらう

作成したコードの内容

今回は、こんな感じの操作を行うコードを生成してみる。

阿部寛のHPを開く
プロフィールページへのハイパーリンクを押下し遷移する

Pageインスタンスの取得を簡素化

Playwrightを利用する際には、前準備として以下のステップを踏む必要がある。

Playwrightインスタンスの生成
PlaywrightインスタンスからBrowserインスタンスを取得
BrowserインスタンスからContextを取得
ContextからPageインスタンスを生成

このステップがなかなか呪文じみており、毎回ググる未来しかない。
そのため、このステップを簡略化するメソッドを作成してもらった。

Ctrl+Iを押すとプロンプトが開くので、ここに自然言語で指示を入力する。
一番最初のPlaywrightインスタンスはTry文で囲みたいため、生成済みのPlaywrightインスタンスを仮引数として指定する形で指示した。

すると、以下のようなコードが提案された。
コードとしては正しいが、1行にまとまりすぎていて可読性が低い。

そのため、即座にAcceptはせず、「複数行に分けて」という追加指示を与えた。
すると、いい感じに分けてくれた。

ここまで作成されたメソッドを呼び出し、navigate()すれば阿部寛のHPを開くところまでは実行可能である。

ハイパーリンクをクリックするメソッドを作成

続いて、ブラウザの画面上で特定の文字列を含むハイパーリンクを探索し、押下するメソッドを作ってもらった。
最初に提案されたコードが完全一致検索になっていたため、「部分一致にして」と追加指示を与えたところ、希望通りのコードが生成された。

ここで面白かったのが、Playwrightオブジェクトを起点としてPageインスタンスを取得するコードが生成されなかったことである。
指示に「仮引数にPageインスタンスを含めて」等とは一切書いていないが、上記で作成したgetPage()メソッドの存在を考慮し、不要と判断したのだろうか。

既存メソッドを利用したコードの生成

ここまでくれば、各メソッドを呼び出すだけで「阿部寛のHPを開いてプロフィールページに遷移する」を実装するできる。
しかし、既存のコードを考慮した上でコード生成してくれるのであれば、せっかくなら書いてもらいたい。
ということで、操作内容を指示した。

すると、上記で作成したgetPage()やclickByText()を利用したコードをちゃんと生成してくれた。

生成されたコードの実行

AIによって生成されたコードを実行すると、期待通りの動作をしてくれた。

おわりに

利用する生成AIに好みがないならば、完全無料でAIにコーディングしてもらえるのは非常にありがたい。
「有料の生成AIでないと使い物ならない」という意見も見かけたが、QAエンジニアのように「コーディングを生業にしない人」「複雑なコーディングはしない人」としては、無料AIでも十二分に有用に思えた。

また、脈絡のないコードを生成するのではなく、既存のオブジェクトをちゃんと利用したコードを書いてくれる点は、可能性を広げてくれそう。
例えば、PlaywrightにHTML要素を正確に認識させるには、querySelector()を知っている必要がある。
しかし、これを網羅的に記憶するのは大変だし、QAチーム全体に学習を強制するのも辛い。
そのため、今回のclickByText()メソッドのように、クエリがうろ覚えなままでも実装できる仕組みにすると、保守性・可読性が上がりそうだ。
Utility的な感じで頻用メソッドをあらかじめ作っておき、生成AIにはこれらを利用したコードを作成してもらう。
こうすることで、自然言語の指示からPlaywrightコードを自動生成させる仕組みが構築できるかもしれない。
　
　
　
従来の自動テストツールは、収録済み要素の認識にAIを活用したり(オートヒーリング)、アサーションにAIを活用する形が多かった。
いずれも画面が既に存在することを前提としたものであり、「回帰テストの自動化」という枠組みを越えていない。

今回の検証で感じたのは、「うまく使えばまだ存在しない画面の自動テストを実装できるかもしれない」である。