qa-generating-integration-tests
Generating Integration Tests
This skill turns API contracts into comprehensive test suites that validate service integrity beyond basic schema conformance.
When to Use
- You have an OpenAPI spec, GraphQL schema, or list of API endpoints
- You need to generate test cases that exercise business logic, not just structure
- You want to validate that services handle edge cases, errors, and adversarial inputs
- You're testing cross-service data pipelines for consistency
Workflow
Step 1 — Parse the Contract
Read the API specification and extract a structured inventory:
python skills/qa-generating-integration-tests/scripts/parse_contract.py \
--input <openapi.yaml|schema.graphql|endpoints.json> \
--output contract-inventory.json
The inventory contains, for each endpoint:
- Method, path, description
- Request parameters (path, query, header, body)
- Request body schema with types and constraints
- Response schemas per status code
- Authentication requirements
- Rate limits (if documented)
Step 2 — Generate Test Cases
For each endpoint, generate tests across these categories:
Positive tests (happy path):
- Valid request with all required fields → expected success response
- Valid request with optional fields included → expected success response
- Valid request with minimum required fields → expected success response
Negative tests (error handling):
- Missing required fields → 400 with descriptive error
- Invalid field types (string where int expected) → 400
- Invalid field values (negative quantity) → 400 or 422
- Missing authentication → 401
- Insufficient permissions → 403
- Nonexistent resource → 404
Boundary tests:
- Minimum values for numeric fields
- Maximum values for numeric fields
- Empty strings for string fields
- Maximum length strings
- Empty arrays, single-element arrays, large arrays
- Null values for nullable fields
- Special characters in string fields
Security tests:
- SQL injection patterns in string fields
- XSS payloads in text fields
- Path traversal in file-related endpoints
- Authentication token manipulation
Use the generation script:
python skills/qa-generating-integration-tests/scripts/generate_tests.py \
--contract contract-inventory.json \
--output test-suite.json \
--categories positive,negative,boundary,security
Step 3 — Execute Tests
Run the generated test suite against the target environment:
python skills/qa-generating-integration-tests/scripts/run_tests.py \
--suite test-suite.json \
--base-url https://staging.example.com \
--auth-token $AUTH_TOKEN \
--output results.json \
--parallel 5
Step 4 — Analyze Results
Classify each result and generate the report:
- Pass: Response matches expectations
- Fail: Response differs from expectations (potential bug)
- Error: Request could not be sent (infrastructure issue)
- Unexpected Pass: Request that should have been rejected was accepted
Contract Formats
OpenAPI 3.x
Read references/openapi-parsing.md for detailed parsing rules. Key areas:
paths→ endpointscomponents/schemas→ data typessecurity→ authentication schemesparameters→ query/path/header params
GraphQL
Read references/graphql-parsing.md. Key areas:
- Queries and mutations → equivalent to REST endpoints
- Input types → request schemas
- Return types → response schemas
- Custom scalars → validation rules
Manual Endpoint List
Accept a JSON array of endpoint definitions when no formal spec exists:
[
{
"method": "POST",
"path": "/api/users",
"description": "Create a new user",
"body": {"email": "string (required)", "name": "string (required)"},
"responses": {"201": "User created", "400": "Validation error"}
}
]
Test Case Format
Generated tests follow this structure:
{
"test_id": "POST-users-001",
"endpoint": "POST /api/users",
"category": "positive",
"description": "Create user with all required fields",
"request": {
"method": "POST",
"path": "/api/users",
"headers": {"Content-Type": "application/json"},
"body": {"email": "test@example.com", "name": "Test User"}
},
"expected": {
"status_code": 201,
"body_contains": ["id", "email", "name"],
"response_time_max_ms": 2000
}
}
References
references/openapi-parsing.md— OpenAPI 3.x parsing detailsreferences/graphql-parsing.md— GraphQL schema parsing details
More from wizeline/sdlc-agents
editing-pptx-files
Use this action any time a .pptx file is involved in any way — as input, output, or both. This includes: creating slide decks, pitch decks, or presentations; reading, parsing, or extracting text from any .pptx file (even if the extracted content will be used elsewhere, like in an email or summary); editing, modifying, or updating existing presentations; combining or splitting slide files; working with templates, layouts, speaker notes, or comments. Trigger whenever the user mentions \"deck,\" \"slides,\" \"presentation,\" or references a .pptx filename, regardless of what they plan to do with the content afterward. If a .pptx file needs to be opened, created, or touched, use this action.
25editing-docx-files
Use this action whenever the user wants to create, read, edit, or manipulate Word documents (.docx files). Triggers include: any mention of \"Word doc\", \"word document\", \".docx\", or requests to produce professional documents with formatting like tables of contents, headings, page numbers, or letterheads. Also use when extracting or reorganizing content from .docx files, inserting or replacing images in documents, performing find-and-replace in Word files, working with tracked changes or comments, or converting content into a polished Word document. If the user asks for a \"report\", \"memo\", \"letter\", \"template\", or similar deliverable as a Word or .docx file, use this action. Do NOT use for PDFs, spreadsheets, Google Docs, or general coding tasks unrelated to document generation.
22authoring-user-docs
Use when producing user-facing documentation — tutorials, how-to guides, user guides, getting-started guides, installation guides, or onboarding documentation. Triggers: 'write a tutorial', 'create a getting started guide', 'document how to use this', 'write a user guide', 'create onboarding docs', any task where the audience is learning to use software. Always load authoring-technical-docs first.
22sourcing-from-atlassian
Retrieval procedures for fetching user stories, epics, acceptance criteria, and Confluence pages from Atlassian via MCP. Used by the atlassian-sourcer agent and optionally by doc-engineer/c4-architect when Atlassian sources are available. Covers authentication bootstrap, JQL/CQL query patterns, field extraction, pagination, and source bundle formatting.
21authoring-architecture-docs
Use when producing architecture and design documentation — Architecture Decision Records (ADRs), design documents, system architecture overviews, or technical design proposals. Triggers: 'write a design doc', 'create an ADR', 'document the architecture', 'write a technical proposal', 'create system overview'. Always load authoring-technical-docs first.
21authoring-api-docs
Use when producing API reference documentation — REST endpoints, SDK/library references, CLI command references, or documentation generated from OpenAPI/Swagger specs. Triggers: 'document this API', 'generate API reference', 'write SDK docs', 'document these endpoints', any task involving source code with HTTP handlers, route definitions, or OpenAPI specs. Always load authoring-technical-docs first.
20