integration-test-advisor
Integration test patterns — adapter testing, external service mocking, test slicing
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Integration test patterns — adapter testing, external service mocking, test slicing
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | integration-test-advisor |
| scope | ["backend","testing"] |
| description | Integration test patterns — adapter testing, external service mocking, test slicing |
| version | 1.0 |
| tags | ["testing","integration-tests","adapters","mocking","database"] |
Guide the design of integration tests that verify how components collaborate across boundaries — specifically how adapters interact with databases, external HTTP services, and messaging systems.
Integration tests verify that adapters work correctly with their external dependencies. They sit between unit tests (fully isolated) and end-to-end tests (full system).
Test at the boundary — not through the domain:
Test infrastructure adapters at their boundary: repositories (DB), HTTP clients, message publishers/consumers, cache adapters, file storage adapters.
Do NOT include in integration tests: business logic, domain rules, controller routing, or authentication middleware.
A test slice loads only the components needed for the integration test — not the full application context. Use @DataJpaTest (Spring), @WebMvcTest, or equivalent framework-specific annotations to load only the relevant slice.
Detailed patterns and examples are available in the references/ directory. Load these on demand when the review touches the specific topic.
references/wiremock-patterns.md for WireMock stub patterns, verification, and fault injection examples (Java/HTTP).references/testcontainers.md for TestContainers setup with real database instances in integration tests.references/msw-patterns.md for MSW (Mock Service Worker) patterns for TypeScript/HTTP service mocking.references/database-testing.md for database integration test setup/teardown strategies and assertion patterns.Before finalizing your review, check gotchas.md for common Claude mistakes in this domain.
When reviewing integration tests:
This skill supports advisor mode: when invoked by the SDD orchestrator with a GUIDANCE CONTEXT FROM PLANNER block in the prompt, use the following procedure instead of the standard interactive review flow.
Advisor mode is active when the prompt contains:
GUIDANCE CONTEXT FROM PLANNER: blockCURRENT PLAN EXCERPT: blockGUIDANCE CONTEXT FROM PLANNER block to understand what the planner needs reviewed.CURRENT PLAN EXCERPT to see the specific tasks and design decisions.Focus ONLY on your specialist domain: @AdapterIT patterns, SimulationRepository, external service mocking.
### Strengths
- [What looks sound in the plan from this skill's domain perspective]
### Issues Found
[Severity: Critical / Major / Minor — reference specific task IDs or section names]
- T001: [issue description]
### Recommendations
[Specific, actionable. Reference task ID or section name for each recommendation.]
- T001: [recommendation]
Save full advice output to engram:
mem_save(
title: "sdd/{change-name}/guidance/integration-test-advisor",
type: "architecture",
project: "{project-name}",
content: "{your full structured advice output}"
)
If engram is unavailable, skip silently.
Return a concise summary (3-5 bullet points) plus the engram observation ID:
### Summary
- [key point 1]
- [key point 2]
- ...
### Engram ID
{observation_id or "unavailable"}
Do NOT return an SDD Envelope when in advisor mode.
Use when creating an SDD implementation plan from exploration.md, with deep interview, task breakdown, and batch assignments.
Generate a Product Requirements Document via interactive interview. Writes a markdown PRD that captures intent, user stories, and out-of-scope. Use when the brief is vague, when no ticket is bound, or when SDD invokes it from its PRD gate.
Use when executing an SDD plan via batch-based task implementation, tracking progress with [ ]/[X] markers and quality gates.
Use when starting an SDD workflow to discover codebase context, curate relevant files, and prepare exploration.md for planning.
SDD Orchestrator coordinates SDD (Spec-Driven Development) workflow via sub-agents
Use when reviewing code changes before commit, comparing implementation against SDD plan, or doing standalone code review with advisor consultation.