Codeceptionのgenerateコマンド徹底解説｜E2E・ユニットテストを自動生成する最速テクニック

本記事には広告が含まれています

2025/06/02

近年のアジャイル開発では「動くコード」をいかに早く保護できるかが競争力に直結します。
Codeception は CLI からテスト雛形を自動生成できるため、実装と同時にテストを書く文化を自然に根付かせられます。

特に generate:cest や generate:test などのコマンドは、コード補完済みのファイルを数秒で用意してくれるため、テストを書くハードルを劇的に下げます。

この記事では CLI コマンドの全体像と使い分け、CI/CD での運用までを実例ベースで解説します。

CLI の全体像：generate 系コマンド一覧

Codeception の CLI では “g:” という短縮表記も含め、十種類以上の雛形生成コマンドが提供されています。主要なものを整理すると次表のとおりです。

コマンド	生成物	主なユースケース
generate:cest (g:cest)	◎Cest クラス	E2E テスト・API テスト
generate:test (g:test)	◎PHPUnit 互換 Test クラス	ユニットテスト
generate:feature (g:feature)	.feature ファイル	Gherkin + BDD ※ Codeception 単体での実行は限定的
generate:helper (g:helper)	Helper クラス	共通アクションの再利用

※ generate:scenarios は旧形式向けで、現行バージョンでは非推奨です。

実運用で最も使われるのが generate:cest です。たとえば codecept g:cest acceptance Login と入力すると LoginCest.php が瞬時に生成され、_before() とサンプルメソッド tryToLogin() が挿入されます。

開発者は $I オブジェクトを用いて「ページにアクセス→要素を入力→送信」などの手順を書くのみ。アクター名を変えたい場合は --actor オプションで AdminTester などを指定できます。これにより、ドメイン固有の DSL を取り込みつつテストを読みやすく保てます。

SPA では描画タイミング差異で要素探索に失敗することがあります。$I->waitForElement('.login') などのステップを雛形に追加しておくと、後々のデバッグ工数を削減できます。

ビジネスロジック層の検証には generate:test が便利です。PHPUnit 互換クラスが生成されるため、IDE がもつ PHPUnit インスペクション機能をそのまま使えます。

モックやスタブには Codeception の make() 系ヘルパーが利用可能で、Laravel／Symfony などのデファクトフレームワークとも親和性が高い点が採用理由として挙げられます。

Helper クラスにファクトリメソッドを集約しておくと、テストだけでなく開発コードにも再利用でき、二重管理を避けられます。

generate:feature は Gherkin シンタックスで .feature ファイルを生成します。ただし Codeception 単体での実行は限定的で、実際には Behat 連携や CI での共有仕様書としての利用が一般的です。

BDD をチーム文化として取り入れる場合は、codecept run --gherkin ではなく Behat + Codeception のハイブリッド構成も検討すると良いでしょう。

API 専用スイートを用意したい場合、現在の公式ガイドでは codecept bootstrap で共通セットアップを作成し、その後 codecept init "api" で api.suite.yml を生成する方法が推奨されています。

かつての “generate:suite api” のようなワンライナーは存在しないため注意してください。init 実行後に modules: に REST あるいは GraphQL を追加し、ApiTester クラスが Actor として生成される流れが定石です。

テストを実行する CI ランナーでは composer install --dev --prefer-dist --no-interaction を推奨します。--no-dev を付けると codeception/codeception 自体が入りません。

一方、本番環境にデプロイするジョブではセキュリティとサイズ削減のため --no-dev --optimize-autoloader を使用する、という使い分けが安全です。

codecept run --group acceptance --parallel を指定すると、スイート単位で並列実行され、GitHub Actions の matrix 機能と組み合わせれば実行時間を半減できます。

Class ‘AcceptanceTester’ not found
→ codecept build の実行漏れ。スイート設定変更時は必ずビルド。
Module REST is not enabled
→ api.suite.yml の modules セクションに - REST を追加し、必要なら composer require codeception/module-rest --dev。
Cannot find element “.btn-login”
→ SPA 特有の描画遅延。waitForElement や waitForJS をステップ前に設置。
Unexpected response code 500
→ API 側の例外。_before() でフィクスチャ投入を忘れていないか確認。