# Integration E2e Testing

Defines integration/E2E skeleton annotations, lane and file contracts, and route-parity...

- Repository: https://github.com/shinpr/claude-code-workflows (708 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-10-29
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add shinpr/claude-code-workflows --skill integration-e2e-testing -g -a claude-code -y`
Codex: `npx skills add shinpr/claude-code-workflows --skill integration-e2e-testing -g -a codex -y`
Cursor: `npx skills add shinpr/claude-code-workflows --skill integration-e2e-testing -g -a cursor -y`
Gemini CLI: `npx skills add shinpr/claude-code-workflows --skill integration-e2e-testing -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add shinpr/claude-code-workflows`

## Description

Defines integration/E2E skeleton annotations, lane and file contracts, and route-parity review criteria. Use when generating or consuming test skeletons or reviewing shared mutation routes.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Integration and E2E Skeleton Contracts

## Test Lanes

| Lane | Observable boundary | Dependencies |
|------|---------------------|--------------|
| `integration` | Interactions within a process, including framework-rendered UI and module/API handlers | Real participating components; mock only outside the claimed boundary |
| `fixture-e2e` | Actual UI behavior in a real browser with deterministic fixtures | Fixtures may replace dependencies outside the claimed boundary |
| `service-integration-e2e` | Outcome depends on actual cross-service interaction or persistence | Required local services and stores are real; stubs only outside that proof boundary |

## Test Skeleton Specification

### Required Comment Patterns

Each test MUST include the following annotations:

```
AC: [Original acceptance criteria text]
Behavior: [Trigger] → [Process] → [Observable Result]
@lane: integration | fixture-e2e | service-integration-e2e
@dependency: none | [component names] | full-system
Selection evidence: [required claim, uncovered failure, and why cheaper existing proof is insufficient]
```

Use the project's comment syntax to wrap these annotations (e.g., `//` for C-family, `#` for Python/Ruby/Shell).

### Verification Items (Optional)

When verification points need explicit enumeration:
```
Verification items:
- [Item 1]
- [Item 2]
```

## Test File Naming Convention

- Integration tests: `*.int.test.*` or `*.integration.test.*`
- fixture-e2e tests: `*.fixture.e2e.test.*` (or organize under `tests/e2e/fixture/`)
- service-integration-e2e tests: `*.service.e2e.test.*` (or organize under `tests/e2e/service/`)

The test runner or framework in the project determines the appropriate file extension. Repos that already use a single `*.e2e.test.*` convention may keep it as long as each file declares `@lane:` in its header, the lane annotation is the source of truth for routing.

## Route Parity for Shared Mutations

The rest: https://github.com/shinpr/claude-code-workflows/blob/HEAD/dev-skills/skills/integration-e2e-testing/SKILL.md