MCP Fusion/Operate and integrate/テスト
テスト
@mcpfusion/testing はツールを実際のパイプラインでメモリ内実行します。サーバーもトークンも不要で、バリデーション、ミドルウェア、redaction、Presenter を完全な忠実度で検証します。
MCP サーバーのテストは普通、プロトコルをモックして確信を失うことになります。@mcpfusion/testing は逆を行きます。実際のレジストリを実際のパイプラインでメモリ内実行するため、成功したテストは本番が実行するのと同じコードパスを検証します。
bash
npm install @mcpfusion/testingハーネス
typescript
import { createMCPFusionTester } from '@mcpfusion/testing';
import registry from './src/server';
const t = createMCPFusionTester(registry, { contextFactory: () => ({ db: testDb }) });
test('get_invoice hides PII and teaches units', async () => {
const result = await t.callAction('billing', 'get_invoice', {
id: 'inv_2026_0417',
});
expect(result.data.email).toBeUndefined();
expect(result.systemRules).toContain(
'amount_cents is in CENTS. Divide by 100.',
);
expect(result.rawResponse).toContain('billing.remind');
});1 回の呼び出しで、アサーションはエージェントが受け取るものを正確に検査します。redaction 後の構造化コンテンツ、Presenter が注入するシステムルール、提示される affordances です。
本物として動くもの
| 段階 | 忠実度 |
|---|---|
| 入力バリデーション | builder からの本物の Zod スキーマ |
| ミドルウェア | 本物のチェーン、本物のコンテキスト導出 |
| Redaction | 本物のコンパイル済み redaction 関数 |
| Presenter の整形 | 本物のスキーマ、ルール、UI ブロック、affordances |
| トランスポート | モック。置き換えられる唯一の部分 |
ハーネスはサーバーもトークンもなしでメモリ内実行のため、テストは毎回の push、CI でも実行できる速さです。
何をテストするか
- Egress 契約。
result.dataに PII フィールドが存在しないことをアサートします。誰かがフィールドを追加して redaction パスを忘れた日に捕まえるのが、このテストです。 - ルール。 Presenter が約束する単位と通貨の行が
systemRulesに含まれることをアサートします。 - Affordances。 状態ごとに
.suggest()が正しい次のアクションを提示することをアサートします。 - 失敗の形。
Resultの失敗がavailableActions付きで返ることをアサートし、エージェントが自己修復できるようにします。 - 状態ゲート。 FSM に結合したツールでは、禁止する状態のツール一覧にそのツールが現れないことをアサートします。
AI コーディングエージェントがツールを書いたなら、ここでその仕事を検証します。SKILL.md 契約がエージェントにパターンを約束させ、これらのテストが CI にそれを強制させます。Skills を参照してください。
CI
bash
npx vitest run
mcpfusion lock --check ./dist/server.jsハーネスを Governance の capability lockfile チェックと組み合わせてください。テストが振る舞いを検証し、lockfile がサーフェスの逸脱がないことを検証します。2 つ揃って、すべての変更がデプロイ前に通る 2 つの門です。
次のステップ
- Tools：ハーネスが鍛えるもの
- Governance：lockfile と CI の門
- Deploy：確信を持って、無料で出荷