HTTP中心のテスト体制
NaifyはユニットテストやPHPUnitを否定しません。
そのうえでNaify自体の品質運用では、Webアプリの確認にHTTP経由のテストも組み合わせています。
原則:テストはHTTP経由で実行する
Webアプリケーションの確認は、まずWebサーバー上でHTTPを通して行います。ブラウザからアクセスできるテストは、人間にも機械にも扱いやすいです。
CLIテストだけでは確認しにくい挙動があるため、HTTP経由の確認も基準にしています。
PHPUnitとHTTPテストの位置づけ
PHPUnitやPestなどのCLIテストは有用であり、採用するかどうかはアプリ側で決められます。Naify自体の運用では、それに加えてHTTP経由の確認も行っています。
CLIのテストが通っていても、Webサーバーやネットワーク機器を通したときの挙動は、HTTP経由で別に確かめる必要があります。
CLIテストでは再現しにくく、HTTP経由で確認しやすいもの：
- WAF（Web Application Firewall）がリクエストをブロック
- mod_securityがPOSTボディを検閲
- リバースプロキシがヘッダーを書き換え
- セッション / Cookieの挙動がCLIと異なる
- CORS / CSP /認証ミドルウェア
- php.iniがCLIとFPMで別設定
CLIテストとHTTPテストの役割比較
| 観点 | CLIテスト | HTTPテスト |
|---|---|---|
| 実行環境 | CLI（php vendor/bin/phpunit） | Webサーバー（HTTP経由） |
| 確認方法 | CLI出力やCIのレポート | ブラウザやcurlで確認 |
| WAF /ミドルウェア | 通常は対象に含まれない | 経路上にあれば対象に含まれる |
| セッション / Cookie | モックなどで再現する | 実際の往復を確認できる |
| 自動化 | CIに組み込みやすい | curl + JSONで自動判定できる（CI連携にはサーバー起動などの準備が必要） |
| 実行コスト | 軽い | サーバー起動が必要 |
| 追加ツール | Composer +テストフレームワーク | サーバー + HTTPクライアント |
| ブラウザでの確認 | 対象外（自動化にはSelenium等が別途必要） | テストURLをブラウザで開いて手動確認できる（JavaScriptの自動テストには別途ツールが必要） |
純粋なロジック
型や戻り値の整合
失敗箇所の切り分け
実行の速さ
Cookieの往復
セッション維持
Header / Redirect / Content-Type
Webサーバー越しの挙動
HTTPテストのメリットとトレードオフ
HTTPテストは、アプリ全体をHTTP経由で確認する統合テストに近いです。
| 項目 | メリット | デメリット /注意点 |
|---|---|---|
| 実動作 | 本番に近い条件で確認できる | サーバー起動が前提になる |
| セッション / Cookie | ログイン状態やCookie往復まで確認できる | 単体テストよりセットアップが重い |
| CI連携 | JSONエンドポイントを使えば自動判定できる | CLIだけで閉じる方式ではない |
| 障害調査 | ブラウザでそのまま再現確認できる | 失敗時の原因切り分けはCLIテストより粗くなりやすい |
Naifyが重視しているのはCLIを捨てることではありません。Webアプリの確認に、HTTP経由の動作も含めることを重視しています。PHPUnitを含む単体テストやCLIテストは、必要に応じてアプリ側で併用できます。
テストで確認する内容
実際のHTTPリクエストを使い、応答内容とステータスコード、Cookie、セッション、リダイレクトを確認します。DB操作では、読み書きの結果やエラー時の動作も検証します。
確認結果は自動集計し、変更前後の差分や失敗した項目をレビューに利用します。
継続的な検証
変更時のテストと定期的な確認を組み合わせ、既存機能への影響を確認します。未検証の条件や不具合が見つかった場合は、再発を確認できるテストを追加します。
AIは調査やレビューを補助し、変更内容とテスト結果の最終確認は人間が行います。
テスト結果の信頼性を保つ
仕様変更がある場合は、その理由とテストへの影響を確認します。失敗を解消するためだけに期待値を変更せず、不具合と仕様変更を区別して扱います。