mcpField
N
ns-code-backend-tests

ns-code-backend-tests

github.com/nextstage-brasilテスト・品質054 回インストール6 日前に更新
リポジトリ

ns-code-backend-tests について

PHPプロジェクトでバックエンドの PHPUnit テストを実装するスキルです。テストルートの検出または初期構築、既存パターンの確認を行い、指定された Docker テストコンテナ内での実行を求めます。

主な機能

  1. 01PHPUnit 設定の検出または構築
  2. 02コードと既存テストの確認
  3. 03ユニット・HTTP 機能テストの作成
  4. 04Docker コンテナ内でのテスト実行
  5. 05結果と阻害要因の報告

活用シーン

  1. 01バックエンド変更へのテスト追加
  2. 02認証・テナント分離エンドポイントのテスト
  3. 03バックエンドパッケージのテスト構造構築

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/nextstage-brasil/skills --skill ns-code-backend-tests

インストール後、Claude Code で/ns-code-backend-testsを入力して読み込まれたか確認します。

同梱ファイルevals/evals.jsonreferences/backend-testing-architecture.md

詳細

バックエンドテストの作成

実行フェーズの PHPUnit 実装です。計画フェーズ：ns-pm-unit-test-task-generator。

ハーネスの確認

{harness_root}/rules/backend-tests-rules.mdc と backend-rules.mdc がある場合は読み込んでください。レイアウト、実行契約、ブートストラップの概要については、references/backend-testing-architecture.md を参照してください。

フェーズ 0 — バックエンドテストのルートを特定またはブートストラップする

テストクラスのコードを書く前に、PHPUnit プロジェクトを特定するか、最小限の構成を作成してください。

0.1 — 既存のテストを検出する（ブラウンフィールド）

{product_root} を次の順序で検索します。

  1. backend/phpunit.xml
  2. {product_root}/ の phpunit.xml
  3. PHPUnit を含む composer.json があるディレクトリ配下の tests/Unit/ または tests/Feature/

phpunit.xml があるディレクトリを {backend_root} として記録してください。以下のすべてのパスは {backend_root} からの相対パスです。

0.2 — 何もない場合にブートストラップする（グリーンフィールド）

バックエンドのアプリケーションコード（app/、src/、または同等のもの）はあるものの、phpunit.xml と tests/ がない場合：

ルール詳細
場所モノレポの場合は {product_root}/backend/、それ以外は {product_root}/
ツリーreferences/backend-testing-architecture.md に従います — phpunit.xml、tests/TestCase.php、tests/Unit/、tests/Feature/
依存関係既存の composer.json 経由で PHPUnit を使用します — フロントエンドや無関係なパッケージには追加しないでください

次に、そのディレクトリを {backend_root} に設定します。

グリーンフィールドで禁止されていること： テストがすでにあると想定すること、ホスト上で PHPUnit を実行すること、またはバックエンドパッケージ外にテストのひな型を作成すること。

0.3 — ブートストラップ後のドキュメント更新

{product_root}/docs/context/stack-confirmed.md または architecture-rules.md がある場合は、バックエンドテストの行を追加または更新してください。記載する内容は、{backend_root}、Docker テストコンテナ、フェーズ 5 の PHPUnit 実行コマンドです。

{backend_root} が確定し、phpunit.xml が読み取り可能になるまで、フェーズ 1 に進まないでください。

フェーズ 1 — 調査（機能コードを書く前）

  1. テスト対象コード — 実装ファイル（Service、FormRequest、Controller など）を読みます
  2. 既存のテスト — tests/Unit/ と tests/Feature/ にある対応ファイルを読みます。重複させず、拡張してください
  3. プロジェクトのパターン — ハーネスルールに従い、ファクトリー、RefreshDatabase、レスポンスエンベロープ、マルチテナンシーヘルパーを確認します
  4. タスクの契約 — ns-pm-unit-test-task-generator のタスクを実装する場合は、そのシナリオチェックリストに従います

フェーズ 2 — テストを作成する

  • ユニットテスト：依存関係をモックし、実際の DB／キュー／キャッシュへの I/O は行いません
  • フィーチャーテスト：認証、401／403、該当する場合はクロステナント P0 を含む HTTP テスト
  • 命名：{Component}Test.php、説明的な snake_case のメソッド名
  • モジュールパスに合わせます：tests/Unit/Modules/{Domain}/、tests/Feature/Modules/{Domain}/

フェーズ 3 — 実行（必須の契約）

../ns-harness/references/docker-and-testing.md も参照してください。

  1. docker ps を実行し、ドキュメントに記載された テスト コンテナを確認します（未記載の場合は一度だけ確認してください）
  2. {backend_root} を作業ディレクトリとして、テストコンテナ内で実行します。
timeout 120 docker exec -w {workdir} {test_container} \
  vendor/bin/phpunit --testdox --stop-on-failure --stop-on-error {optional_filter}
  1. タイムアウト： コマンドが 120 秒で強制終了された場合（例：終了コード 124）、実行は停止またはハングしたものとして扱います。中止してブロッカーを報告し、黙って再試行しないでください
  2. ホスト上で vendor/bin/phpunit または phpunit.sh を実行することは禁止です

フィルター実行（単一クラスまたはメソッド）にも、同じフラグとタイムアウトを使用します。

フェーズ 4 — 報告

  • 成功：追加または変更したファイルを列挙します
  • 失敗：--testdox の出力から、最初に失敗したテスト名とアサーションを示します
  • ハング／タイムアウト：120 秒の制限を超えたことを明記します。根本原因が不明な場合は ns-code-investigator を呼び出します

参照資料

ファイル用途
references/backend-testing-architecture.mdレイアウト、ブートストラップ、実行契約
ns-pm-unit-test-task-generatorタスク契約のソース

関連スキル

  • ns-pm-unit-test-task-generator — 計画タスク
  • ns-code-investigator — 失敗またはハングしたテストのデバッグ
  • ns-code-coder — 計画されたユニットテストタスク以外の臨時修正

コメント

Markdown 対応