mcpField
R
reproduce-bug

reproduce-bug

github.com/n8n-ioテスト・品質208.9k306 回インストール今日更新
リポジトリ

reproduce-bug について

n8n の開発者向けテストスキルで、Linear のチケットをもとにバグを調査し、失敗する回帰テストを作成します。影響範囲に応じてテスト層を選び、確度付きのレポートをまとめます。バグの修正は行いません。

主な機能

  1. 01チケット情報と影響範囲の解析
  2. 02テスト層とパターンの選択
  3. 03コード追跡と仮説の立案
  4. 04失敗する回帰テストの作成と実行
  5. 05再現確度と結果の報告

活用シーン

  1. 01ノードやサービスのバグ再現
  2. 02エディターや API の問題に対するテスト選択
  3. 03現在のコードで回帰が残るかの確認

インストール

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

$npx skills add https://github.com/n8n-io/n8n --skill reproduce-bug

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

詳細

バグ再現フレームワーク

Linear チケットのコンテキスト（$ARGUMENTS）をもとに、失敗する回帰テストを使ってバグを体系的に再現します。

ステップ 1：シグナルを解析する

提供されたチケットのコンテキストから、以下の情報を抽出します。

  • エラーメッセージ／スタックトレース（提供されている場合）
  • 再現手順（提供されている場合）
  • ワークフロー JSON（添付されている場合）
  • 影響を受ける領域（ノード、実行エンジン、エディター、API、設定など）
  • 不具合が発生したバージョン／最後に正常に動作していたバージョン

ステップ 2：テスト戦略を選ぶ

影響を受ける領域に応じて、テスト層とパターンを選択します。

領域テスト層パターン主な配置場所
ノードの操作Jest 単体テストNodeTestHarness + nockpackages/nodes-base/nodes/*/test/
ノードの認証情報Jest 単体テストjest-mock-extendedpackages/nodes-base/nodes/*/test/
トリガーの WebhookJest 単体テストmock IHookFunctions + jest.mock GenericFunctionspackages/nodes-base/nodes/*/test/
バイナリデータJest 単体テストNodeTestHarness assertBinaryDatapackages/core/nodes-testing/
実行エンジンJest 統合テストWorkflowRunner + DI コンテナーpackages/cli/src/__tests__/
CLI／APIJest 統合テストsetupTestServer + supertestpackages/cli/test/integration/
設定Jest 単体テストGlobalConfig + Containerpackages/@n8n/config/src/__tests__/
エディター UIVitestVue Test Utils + Piniapackages/frontend/editor-ui/src/**/__tests__/
E2E／キャンバスPlaywrightテストコンテナー + composablespackages/testing/playwright/

ステップ 3：ソースファイルを特定する

影響を受ける領域のソースコードを探します。

  1. チケットに記載されたノード／サービス／コンポーネントを検索します
  2. GenericFunctions ファイルを探します（ノードでよくバグが発生する場所です）
  3. 同じ領域に既存のテストファイルがあるか確認します
  4. 影響を受けるファイルの最近の Git 履歴を確認します（git log --oneline -10 -- <path>）

ステップ 4：コードパスを追跡する

ソースコードを読み、バグを引き起こす実行パスを追跡します。

  • エントリーポイントから障害発生箇所までの呼び出しチェーンをたどります
  • バグが発生する具体的な行を特定します
  • バグの周辺にあるエラー処理（またはその欠如）を記録します

ステップ 5：仮説を立てる

明確で検証可能な仮説を述べます。

  • 「[入力／条件] のとき、[根本原因] により、コードが [誤った処理] を行う」
  • 変更が必要な具体的な行を特定します
  • テストの出力に何が表示されるか予測します

ステップ 6：テストパターンを探す

同じ領域の既存テストを調べます。

  1. 影響を受けるコードの近くにある test/ ディレクトリを確認します
  2. 使用されているモック／セットアップのパターンを特定します
  3. 一貫性を保つため、同じパターンを使います
  4. テストがない場合は、最も近い類似ノード／サービスのテストをテンプレートとして探します

ステップ 7：失敗するテストを書く

以下の条件を満たす回帰テストを書きます。

  • ステップ 6 で見つけたパターンを使います
  • ステップ 5 の具体的な仮説を検証します
  • チケット ID を参照するコメントを含めます
  • 正しい動作をアサートします（現行コードではテストが失敗します）
  • セットアップが機能していることを証明する「正常系」のテストも含めます

ステップ 8：実行して評価する

パッケージのディレクトリからテストを実行します（例：cd packages/nodes-base && pnpm test <file>）。

結果を分類します。

確度基準出力
確認済みテストが一貫して失敗し、その失敗が仮説と一致する再現レポート
可能性が高いテストは失敗するが、失敗の仕方が少し異なるレポート + 注意事項
未確認障害を発生させられない試した内容を記載したレポート
スキップ重大な中止条件に該当したスキップした理由を記載したレポート
修正済み現行コードではバグを再現できなくなっている修正時期を記載したレポート

ステップ 9：再試行するか、断念する

最初の試行後も UNCONFIRMED の場合：

  • 仮説を見直します — コードパスを読み直します
  • 別のテスト方法またはレイヤーを試します
  • UNCONFIRMED と判定する前に、試行は最大 3 回までです

即時中止の条件（直ちに中止してください）：

  • 実際のサードパーティ API 認証情報が必要
  • 競合状態、またはタイミングに依存する
  • 特定のクラウド／エンタープライズインフラが必要
  • スクリプト化できない手動の UI 操作が必要

出力：再現レポート

以下の形式で調査結果を提示します：

チケット： [ID] — [タイトル] 確信度： [CONFIRMED | LIKELY | UNCONFIRMED | SKIPPED | ALREADY_FIXED]

根本原因

[バグの仕組みを説明する 1～2 文]

場所
ファイル行問題
path/to/file.tsXX-YY問題の説明
失敗するテスト

path/to/test/file.test.ts — X/Y 件のテストが失敗：

  1. test name — [失敗の説明]
修正のヒント

[修正方法の擬似コードまたは説明]

重要

  • バグを修正しないでください — 失敗するテストで再現するだけにしてください
  • 証拠としてテストファイルを残してください（依頼がない限りコミットしないでください）
  • パッケージのディレクトリからテストを実行してください（例：pushd packages/nodes-base && pnpm test <file> && popd）
  • ビルド出力は必ずリダイレクトしてください：pnpm build > build.log 2>&1
  • 既存の修正 PR を確認しないでください — 手がかりだけをもとに再現することが目的です

コメント

Markdown 対応