SlimでE2Eテストを自動化する方法｜Codeception・Pantherによる実践ガイド

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

2025/05/312025/06/01

SlimでE2Eテストを自動化する方法｜Codeception・Pantherによる実践ガイド

「Slim は軽いからテストは後回しでも大丈夫」――つい抱きがちな油断ですが、マイクロサービスや API ファーストが当たり前になった現在、エンドツーエンド（E2E）テストの自動化は避けて通れません。

ユニットテストでは捕捉し切れない「ルーター設定ミス」「認証ミドルウェアの連携漏れ」など、本番さながらのフローを検証することで初めて安心してリリースできます。

この記事では Slim と相性の良い Codeception・Symfony Panther を中心に、導入手順や CI/CD への組み込み方を現場目線で解説します。

Slim 開発で起こりがちな課題と E2E テストの役割

Slim は “ルーティング＋ミドルウェア” に特化し、ビジネスロジックはサービスクラスに切り出すのが定石です。ゆえに初期開発は爆速ですが、エンドポイントが増えると API 変更の影響範囲 を推測しづらくなります。

さらに Docker コンテナや他のマイクロサービスと組み合わせるケースでは、CORS 設定・ポート競合・トークン共有 といった環境依存の不具合も顕在化しがちです。

こうした“設定由来バグ”を防ぐには、アプリを本物に近い形で立ち上げ、外側から一気通貫で叩く E2E テストが有効です。

Slim であっても小規模だからこそ「後付けの修正コストが相対的に高い」ため、継続的インテグレーション（CI）とセットで最初から導入するのがベストプラクティスと言えます。

Codeception の特徴と Slim へのスマートな組み込み方

Codeception は PHP 製フレームワークのなかでも珍しく、ユニット・機能・E2E を単一 DSL で書けるツールです。

Composer で codeception/codeception を追加後、vendor/bin/codecept bootstrap を実行すると基本のディレクトリ構成が生成されます。

▼Slim プロジェクトでよく使われる設定フロー

tests/_bootstrap.php で \$app = AppFactory::create() を呼び出し、DI コンテナ経由で Slim アプリを作成。
Codeception の REST モジュールと組み合わせ、\$I->sendGET('/health') のように HTTP リクエストを実行。
公式モジュールだけでは補えない場合は codeception-slim-module を追加し、modules: 配下に

    enabled:
        - Slim\Module
    config:
        Slim\Module:
            app: _bootstrap.php

のように記述することで、外部サーバーを立ち上げずにアプリ全体をテストできます。

Symfony モジュールを Slim で直接使う方法も理論上は可能ですが、ミスマッチな設定が多くなるため REST モジュール＋自作ブートストラップの方が現実的です。

Symfony Panther：Slim でも使えるブラウザ E2E テスト

Panther は Headless Chrome／Firefox を PHP から直接ラップし、CSS セレクター を通じて DOM を操作できるライブラリです。

「Laravel Dusk のようなブラウザテスト体験」を Laravel 以外のプロジェクトでも再現できる点が魅力です。Composer で symfony/panther を追加し、テストクラスを PHPUnit で拡張するだけで利用できます。

テストスイート定義の注意
Panther 専用のサブコマンドは存在しないため、--testsuite panther を使う場合は phpunit.xml に

<testsuite name="panther">
    <directory>tests/Panther</directory>
</testsuite>

を先に定義しておく必要があります。

CI で安定させる依存ライブラリ
Chrome のヘッドレス実行には libnss3 だけでなく libxss1, libatk-bridge2.0-0, libasound2, libgtk-3-0 などが必要になる場合があります。複数 OS イメージをまたぐ場合は、Dockerfile や GitHub Actions のジョブ定義で事前に apt-get install -y しておくと安定します。

Codeception と Panther の比較：ケース別に役割分担しよう

観点	Codeception	Symfony Panther
主な対象	REST API / CLI エンドポイント	SPA / SSR 画面操作
ブラウザ制御	Selenium・WebDriver 連携（任意）	Headless Chrome／Firefox 内蔵
セットアップ工数※	中：DSL とモジュール把握が必要	低〜中：テストクラス追加で完結
実行時間※	API だけなら数百 ms	DOM 解析が入るためやや遅い
Slim との親和性	ルーティング・認証の細粒度検証	フロント連携や UX 目線の動作確認

※工数・時間はプロジェクト規模やテストケース数で大きく変動するため、あくまで目安です。

両者は排他的ではなく、API 層＝Codeception、UI 層＝Panther と分担するのが現実的です。

CI/CD への組み込み：GitHub Actions 最小サンプル

E2E テストはローカル実行だけでは不十分です。GitHub Actions を例に、プルリクエストごとにテストを動かす最小ワークフローを示します。

name: e2e
on: [pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    services:
      mysql:
        image: mysql:8.4
        env:
          MYSQL_ROOT_PASSWORD: root
        ports: ["3306:3306"]
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
      - run: composer install --no-progress --ansi
      - name: Run API tests (Codeception)
        run: php vendor/bin/codecept run --html
      - name: Run UI tests (Panther)
        run: php vendor/bin/phpunit --testsuite panther
      - name: Install Chrome deps for Panther
        run: sudo apt-get update && sudo apt-get install -y libnss3 libxss1 libatk-bridge2.0-0 libasound2 libgtk-3-0
      - name: Disable Chrome sandbox (CI)
        env:
          PANTHER_NO_SANDBOX: 1
        run: echo "Sandbox disabled"

ポイント：

テスト用 DB を services として宣言し、本番データを隔離。
依存ライブラリをジョブ内で追加し、Chrome の起動エラーを防止。
環境変数 PANTHER_NO_SANDBOX=1 で Docker 内の seccomp 制限を回避。(ヘッドレス解除の PANTHER_NO_HEADLESS はデバッグ時のみ推奨)

Slim 4 + PHPUnit + Mockery で始めるユニットテスト入門｜DIとモックでテストを自動化