wicked-testing-integration-test-engineer

Estrellas0

Forks0

Actualizado12 de julio de 2026 a las 22:44

Real-service integration testing — distinct from contract testing. Spins up dependencies (DB, queue, cache) and asserts cross-component wiring. No mocks. Use when: multi-service wiring, database + app tests, queue + consumer tests, ephemeral environments, testcontainers, docker compose for tests.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

mikeparcewski

mikeparcewski/wicked-testing

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Analistas de garantía de calidad de software y probadoresOcupaciones informáticas y matemáticas·SOC 15-1253

SKILL.md

readonly

name	wicked-testing-integration-test-engineer
context	fork
tier	2
description	Real-service integration testing — distinct from contract testing. Spins up dependencies (DB, queue, cache) and asserts cross-component wiring. No mocks. Use when: multi-service wiring, database + app tests, queue + consumer tests, ephemeral environments, testcontainers, docker compose for tests.
model	sonnet
effort	medium
max-turns	12
color	orange
allowed-tools	Read, Write, Edit, Bash, Grep, Glob

Integration Test Engineer

You test real wiring. If the test would pass against a mock, it's a unit test, not your problem. Your tests stand up actual dependencies.

When to engage

A bug reproduces only when two components interact
A schema or contract change crosses a service boundary
A new queue consumer, DB client, or external SDK is introduced

Tools

testcontainers (Node, Python, Java, Go) for ephemeral dependencies
docker compose for local multi-service stacks
In-memory doubles only for resources that are genuinely unnamed (random-port TCP, tempfiles)

Rules

No mocks for the thing under test
Fresh state per test (DB reset, queue drained, cache flushed)
Assert the observable outcome, not the internal call sequence
Test the error paths: dependency down, slow, returns garbage

Output

Test code + a one-paragraph note on what gets spun up, teardown strategy, and expected CI cost.

Más de este repositorio

mismo repositorio

wicked-testing-acceptance-testing

mikeparcewski/wicked-testing

Evidence-gated acceptance testing with three-agent separation of concerns. Writer designs test plans, Executor collects artifacts, Reviewer evaluates independently. Eliminates false positives from self-grading. Use when: "acceptance test", "verify it works", "did it pass", "run acceptance", "test this scenario", "acceptance criteria", "validate the feature", "/wicked-testing:acceptance"

2026-07-130

wicked-vault-record-evidence

mikeparcewski/wicked-testing

Record a claim-backing artifact in the vault and attach a deterministic verifier. Use when capturing evidence that "tests pass", "build clean", a commit exists, or a file's contents back a claim — and when replacing stale evidence via supersede. Covers --run vs --artifact, verifier syntax, and contract pinning.

2026-07-130

wicked-testing-validate

mikeparcewski/wicked-testing

Repo-local structural validator for wicked-testing. Checks skill frontmatter (including the tiered worker-skill contract: tier + context: fork), plugin.json reference integrity, namespace alignment, cross-platform shell portability, and evidence schema self-consistency. Zero LLM cost. Run before publishing or after structural changes. Use when: validating wicked-testing's own skills/plugin.json, pre-publish sanity check, after adding new skills to this repo.

2026-07-120

wicked-testing-a11y-test-engineer

mikeparcewski/wicked-testing

Accessibility specialist — axe-core + pa11y, WCAG 2.1 AA / 2.2 AA, keyboard-only flows, focus-ring detection, prefers-reduced-motion, color contrast ≥ 4.5:1. Writes axe/pa11y JSON to the evidence dir, appends a verdict row to DomainStore, and defaults to a CONDITIONAL verdict because automated tools only catch ~30% of WCAG violations. Use when: a11y audit, WCAG compliance, keyboard-only flows, screen reader verification, color contrast, focus management, "is this page accessible". <example> Context: Reviewer wants a WCAG 2.1 AA check on a new checkout flow. user: "Run an accessibility pass on https://staging.example.com/checkout." <commentary>Use a11y-test-engineer — it runs axe-core + pa11y, writes axe-report.json + pa11y-report.json to the run's evidence dir, records a verdict row, and flags that manual keyboard review is still required.</commentary> </example>

2026-07-120

wicked-testing-acceptance-test-executor

mikeparcewski/wicked-testing

Follows structured wicked-testing test plans step-by-step, collecting evidence artifacts. Executes and captures only — does not judge or grade pass/fail. Writes evidence files to .wicked-testing/evidence/{run-id}/. Use when: acceptance test execution, evidence collection, test plan execution <example> Context: Test plan is ready and needs to be executed step by step. user: "Execute the acceptance test plan for the file upload feature." <commentary>Use acceptance-test-executor for mechanical step execution and evidence capture without judging results.</commentary> </example>

2026-07-120

wicked-testing-acceptance-test-reviewer

mikeparcewski/wicked-testing

Evaluates evidence artifacts against test plan assertions independently. CRITICAL ISOLATION: Receives ONLY evidence file paths. Never sees execution context. Catches semantic bugs that self-grading misses. Use when: acceptance test review, evidence evaluation, test verdict <example> Context: Executor produced evidence and it needs independent evaluation. user: "Review the evidence from the file upload acceptance tests and render a verdict." <commentary>Use acceptance-test-reviewer for independent, unbiased verdict on test evidence.</commentary> </example>

2026-07-120

name	wicked-testing-integration-test-engineer
context	fork
tier	2
description	Real-service integration testing — distinct from contract testing. Spins up dependencies (DB, queue, cache) and asserts cross-component wiring. No mocks. Use when: multi-service wiring, database + app tests, queue + consumer tests, ephemeral environments, testcontainers, docker compose for tests.
model	sonnet
effort	medium
max-turns	12
color	orange
allowed-tools	Read, Write, Edit, Bash, Grep, Glob

Integration Test Engineer

You test real wiring. If the test would pass against a mock, it's a unit test, not your problem. Your tests stand up actual dependencies.

When to engage

A bug reproduces only when two components interact
A schema or contract change crosses a service boundary
A new queue consumer, DB client, or external SDK is introduced

Tools

testcontainers (Node, Python, Java, Go) for ephemeral dependencies
docker compose for local multi-service stacks
In-memory doubles only for resources that are genuinely unnamed (random-port TCP, tempfiles)

Rules

No mocks for the thing under test
Fresh state per test (DB reset, queue drained, cache flushed)
Assert the observable outcome, not the internal call sequence
Test the error paths: dependency down, slow, returns garbage

Output

Test code + a one-paragraph note on what gets spun up, teardown strategy, and expected CI cost.