qe-test-generation

QE テスト生成

目的

パターンベースのテスト合成、複数フレームワークへの対応、コード分析からのインテリジェントなテストケース導出など、v3 の AI を活用したテスト生成機能の使い方を説明します。

まず耐久性を重視する（基本ルール）

AI によってコードを低コストで再生成できるようになったとき、実装を破棄して書き直した後も 有効であり続けるテストが、耐久性のある資産となります。テストは耐久性の段階に分けて生成し、 耐久性の高いものから取り組みます（ADR-113）。

段階	内容	書き直し後も有効か？	作成するタイミング
耐久性あり	不変条件、コントラクト／スキーマ、プロパティベーステスト、振る舞いを検証する e2e テスト — モジュールの公開境界で仕様化	はい	必ず作成 — 対象ごとに ≥1 件
一時的	例ベースのユニットテスト、モック呼び出し／インタラクションテスト（TDD のロンドン派スタイル）	いいえ（実装と密結合）	レッド・グリーンループ用。ラベルを付け、自由に削除してください
稼働中	実環境に対して実行するモニタリング／ドリフト／コストのアサーション	継続的	デプロイ後の振る舞い用

言語変更のヒューリスティック： このモジュールを別の言語で再実装するとテストが無効になるなら、 テストの境界が適切ではありません。 段階を上げて、現在のコードがたまたまどのように動作するかではなく、 観測可能なコントラクトをアサートします。

生成するすべての対象には、少なくとも 1 つの耐久性のあるアサーション（不変条件、 コントラクトチェック、またはプロパティ）を含める必要があります。モック呼び出しのアサーション（toHaveBeenCalledWith）は 定義上、一時的なものです。対象をテストする唯一の手段にしてはいけません。各生成テストに // @tier durable|ephemeral|live を付け、その有効期間を明示します。

これらのテストはオラクルとして評価されます。優れたテストは実際のコードでは成功し、 仕込まれたバグ（ミュータント）に対しては失敗します。何もアサートしないテストや、 ハッピーパスだけを検証するテストではミュータントを検出できず、却下されます。/mutation-testing と ADR-113 を参照してください。

有効化

• 新しいコードのテストを生成する場合
• テストカバレッジを改善する場合
• テストを別のフレームワークへ移行する場合
• TDD パターンを適用する場合
• エッジケースのテストを生成する場合

クイックスタート

# Generate unit tests for a file
aqe test generate --file src/services/UserService.ts --framework jest

# Generate tests with coverage target
aqe test generate --scope src/api/ --coverage 90 --type unit

# Generate integration tests
aqe test generate --file src/controllers/AuthController.ts --type integration

# Generate from patterns
aqe test generate --pattern repository --target src/repositories/

エージェントのワークフロー

// Spawn test generation agents — durable-first
Task("Generate durable-first tests", `
  Analyze src/services/PaymentService.ts and generate Jest tests in tier order.
  1. DURABLE (write these first, >=1 per public method):
     - Invariants ("a refund never makes a balance negative")
     - Contract/schema checks on inputs and outputs crossing the boundary
     - Property-based tests (fast-check) over input ranges, not single examples
  2. EPHEMERAL (the red-green loop; tag '// @tier ephemeral'):
     - Specific happy-path examples and error paths
     - Mock external dependencies ONLY — never let a mock-call assertion be the
       only test for a method
  Apply the language-swap check: if a Python rewrite of PaymentService would break
  the test, move it up to the durable tier.
  Output to tests/unit/services/PaymentService.test.ts
`, "qe-test-architect")

// Property + contract generation (first-class, not opt-in)
Task("Generate property and contract tests", `
  For src/repositories/, derive:
  - Properties: round-trip (write→read returns same), idempotence, ordering invariants
  - Contracts: the repository interface schema, enforced on every CRUD result
  These survive a storage-engine swap; example-based CRUD tests do not.
`, "qe-property-tester")

テスト生成戦略

1. コード分析ベース

await testGenerator.analyzeAndGenerate({
  source: 'src/services/OrderService.ts',
  analysis: {
    methods: true,
    branches: true,
    dependencies: true,
    errorPaths: true
  },
  output: {
    framework: 'jest',
    style: 'describe-it',
    assertions: 'expect'
  }
});

2. パターンベースの生成

await testGenerator.applyPattern({
  pattern: 'service-layer',
  targets: ['src/services/*.ts'],
  customizations: {
    mockStrategy: 'jest.mock',
    asyncHandling: 'async-await',
    errorAssertion: 'toThrow'
  }
});

3. カバレッジ主導の生成

await testGenerator.fillCoverageGaps({
  coverageReport: 'coverage/lcov.info',
  targetCoverage: 90,
  prioritize: ['uncovered-branches', 'error-paths'],
  maxTests: 50
});

フレームワークのサポート

フレームワーク	ユニット	統合	E2E	モック
Jest	✅	✅	⚠️	jest.mock
Vitest	✅	✅	⚠️	vi.mock
Mocha	✅	✅	❌	sinon
Pytest	✅	✅	❌	pytest-mock
JUnit	✅	✅	❌	Mockito

テスト品質チェック

quality_checks:
  durability:                  # the primary check (ADR-113)
    durable_assertions_per_target: 1   # >=1 invariant/contract/property each
    language_swap_safe: true           # would survive a reimplementation
    tier_tags_present: true            # every test tagged durable|ephemeral|live

  fault_detection:             # do the tests actually catch bugs?
    mutation_score_min: 0.6            # kill rate against seeded mutants
    no_assertionless_tests: true       # reject tests that kill 0 mutants

  assertions:
    minimum_per_test: 1
    meaningful: true

  isolation:
    no_shared_state: true
    proper_setup_teardown: true

  naming:
    descriptive: true
    follows_convention: true

  coverage:                    # necessary but NOT sufficient — see fault_detection
    branches: 80
    statements: 85

スキルの組み合わせ

• テスト生成後 → /mutation-testing を実行してテスト品質を確認します
• 生成前 → /test-automation-strategy を使用してフレームワークとパターンを選択します
• 関連項目 → /qe-coverage-analysis を使用して、テストが最も必要な箇所を見つけます

注意点

• エージェントは 3000 行を超えるファイルで出力が途中で切れることがあります。ディレクトリ全体ではなく、個別のモジュールに絞って生成してください
• 個々にはユニットテストに合格するコンポーネントでも、統合時の接続がまったくない場合があります。モジュール境界ごとに、少なくとも 1 件の統合テストを必ず生成してください
• 新しいコードベースのテストを生成する場合は、インストールされているフレームワーク（jest、vitest、mocha のいずれか）を確認してください。モック API がそれぞれ異なるため、Claude が誤ったものを使用することがあります
• 完了したように見せかける場合があります。エージェントが「包括的なテストを生成しました」と主張しても、スタブやハードコード値が残っていることがあります。受け入れる前に、生成されたテストを必ず実行してください
• QE エージェントを使用する前に Fleet を初期化する必要があります。aqe health を実行して診断するか、「Fleet not initialized」と表示された場合は aqe init を実行して再初期化してください

連携

主なエージェント: qe-test-generator、qe-pattern-matcher、qe-test-architect コーディネーター: qe-test-generation-coordinator 関連スキル: qe-coverage-analysis、qe-test-execution