edercnj/x-execute-e2e-tests

Global Output Policy

• Language: English ONLY.
• Tone: Technical, Direct, and Concise.
• Efficiency: Remove all conversational fillers and greetings to save tokens.

Skill: End-to-End Tests

Purpose

Run or implement end-to-end tests that validate the complete application flow: inbound request -> parsing -> validation -> business logic -> persistence -> response. Tests use a real database (or in-memory equivalent) and exercise all layers of the architecture.

Activation Condition

Include this skill for all projects with integration test infrastructure.

Triggers

• /x-execute-e2e-tests -- run all E2E tests
• /x-execute-e2e-tests happy-path -- run only happy path scenarios
• /x-execute-e2e-tests persistent -- run persistent connection tests
• /x-execute-e2e-tests all -- run all scenarios explicitly

Parameters

| Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| | scenario | String | No | all | Scenario filter: happy-path, error, timeout, persistent, all |

Knowledge Pack References

| Pack | Files | Purpose | |------|-------|---------| | testing | skills/testing/references/testing-philosophy.md | Real vs in-memory DB decisions, fixture patterns, data uniqueness | | testing | skills/testing/references/testing-conventions.md | {{LANGUAGE}}-specific test framework, assertion library, directory structure |

Prerequisites

• {{FRAMEWORK}} test extension configured
• Database available for tests (in-memory or containerized via {{DB_TYPE}})
• Test dependencies in {{BUILD_FILE}}: assertion library, async utilities
• E2E test classes exist in the test source tree

Workflow

Step 1 — Verify Test Infrastructure

Check that required dependencies exist:

• Framework test extension (e.g., @QuarkusTest, @SpringBootTest)
• Database for tests configured in test profile
• Assertion library available

Step 2 — Run E2E Tests

Execute with:

{{TEST_COMMAND}}

• Filter by scenario tag if a specific scenario was requested
• Ensure test profile is active (in-memory DB, random ports, etc.)

Step 3 — Validate Test Results

• All tests pass (exit code 0)
• No test pollution (each test is independent)
• Database state verified after operations

Step 4 — Report Results

• Total: passed / failed / skipped
• Duration per test class
• Failed tests with error details and stack traces
• Coverage report location (if generated)

Mandatory E2E Scenarios

| Scenario | Description | Priority | |----------|-------------|----------| | Happy path | Standard request processed successfully, persisted | CRITICAL | | Validation error | Invalid input rejected with proper error response | CRITICAL | | Not found | Request for non-existent resource returns proper error | HIGH | | Duplicate/conflict | Duplicate creation attempt returns conflict response | HIGH | | Persistent connection | Multiple requests on same connection (if applicable) | HIGH | | Concurrent requests | Multiple simultaneous requests processed independently | HIGH | | Malformed input | Garbage input handled gracefully without crash | MEDIUM | | Timeout behavior | Slow operations handled per configured timeouts | MEDIUM | | Error recovery | Server continues operating after encountering errors | MEDIUM |

Test Patterns

Test Isolation

• Each test creates its own data, never depends on other tests
• Use unique identifiers per test execution to avoid conflicts
• Automatic cleanup via transaction rollback or explicit teardown

Async Resource Readiness

• Wait for server/socket to be listening before connecting
• Use async polling (not Thread.sleep) for resource readiness
• Default timeout: 10 seconds for resource startup

Assertion Style

• Use fluent assertion library (AssertJ, Chai, etc.)
• Verify both response content AND database state
• Check response status codes, headers, and body

Error Handling

| Scenario | Action | |----------|--------| | Test infrastructure missing | Report missing dependencies with install instructions | | Database unavailable | Report connection failure and suggest starting database container | | Test pollution detected | Warn about shared state and suggest test isolation improvements | | Build fails before tests | Report compilation errors and abort test execution |

Review Checklist

• [ ] Tests exercise the complete flow (input -> all layers -> output)
• [ ] Real or realistic database used (not mocked)
• [ ] Each test is independent and idempotent
• [ ] Unique identifiers generated per test run
• [ ] Async resources awaited with polling (not sleep)
• [ ] Both response and database state verified
• [ ] Error scenarios covered (validation, not-found, conflict)
• [ ] Connection persistence tested (if applicable)
• [ ] Concurrent request handling validated
• [ ] No test pollution between test classes