WebUIのテストを自動化する現場を見かける機会が多くなってくると、導入コストや維持に係るコストといった課題に直面する現場も、よく見るようになりました。SeleniumはCucumberやGaugeと併用することで得られるメリットは大きいのですが、導入が比較的簡単と言われるCodeceptJSを使ってみました。
導入に関する巷の資料も多く存在するので、基本的には、その通りに実行することでテストプロジェクトを設置することができました。
・CodeceptJS + playWright のメリットが大きいと思われる点
Web画面の要素を操作したり、画面から取得するといった基本的なことはデフォルトでバンドル済みな点が、WebDriverを使うSeleniumに比べてハードル低い気がします。Cucumber（テストケースとしてfeatureファイルを記述）やGauge（テストケースとしてspecファイルを記述）では、記述した操作に対応した機能をWebDriverを使って別途コードを書く必要があるのですが、CodeceptJSの場合、テストケースを記述するだけでも、多くのテストに必要な操作ができる点、ハードル低いと感じました。
また、playWrightを使ってブラウザの操作を記録し、コード生成する機能も併用してテストケース記述を行い、テスト実行にもplayWrightが使えるというのも安心感みたいのがありますね。
カスタムstepにも対応していますので、バンドルされていない操作についても対応可能なようです。（未だ試していません）
・CucumberやGaugeと比べて、あまりメリット無いかもしれない点
featureファイル（Gherkin形式、DSLで記述）やspecファイル（Markdownで記述）に比べると、テストケースは、明らかにコードです。自分はJavaScriptやTypeScriptの経験が少ないので、あまり感じませんが、コーダーに言わせるとCodeceptJSのテストケースは、独特のコードだそうです。ローコードあるいはノーコードで自動テストを実装したいと考えている場合は、不向きかもしれません。
ただ、Gherkinのシナリオアウトラインっぽい記述にも対応していますので、テスト期間を通じた仕様変更やテスト項目の見直しによる組み合わせテストの再生成といったシーンにも十分適応できるのではないでしょうか。
テストコード記述をどうしてもしたくない、あるいは、コマンドラインを使いたくない（GUIだけにしたい）場合を除いて、CodeceptJSを自動テストに使う価値はあると感じています。Mobileへの展開含めて、もう少し調査継続です。
