e2e-testing

Design end-to-end tests through public interfaces with production-like dependencies.

2|Updated Aug 4, 2025
One-click install
npx skills add https://github.com/zhu327/go-clean-arch --skill e2e-testing-zhu327
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: e2e-testing
Source: https://github.com/zhu327/go-clean-arch/tree/main/.cursor/skills/e2e-testing
Command: npx skills add https://github.com/zhu327/go-clean-arch --skill e2e-testing-zhu327

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you design and implement end-to-end tests that verify real user-facing behavior through the application’s public interfaces, instead of relying on internal implementation details.

Core Features & Use Cases

  • Public-boundary testing: Exercise HTTP, CLI, queue, or RPC flows the same way a real caller would.
  • Project-specific test strategy: Derive the test runner, fixtures, commands, and cleanup approach from the repository’s existing setup.
  • High-value coverage: Validate success paths, input errors, auth and authorization boundaries, persistence effects, and failure handling in production-like conditions.
  • Use case: A team changes signup or login behavior and uses this Skill to add smoke tests against the live API with real dependencies and isolated test data.

Quick Start

Use the e2e-testing skill to inspect this repository, identify the public contract, and draft the smallest reliable end-to-end test plan for the changed behavior.

Frequently Asked Questions about e2e-testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write end-to-end tests for an HTTP API with real dependencies?

End-to-end testing for an HTTP API involves verifying application behavior through public interfaces and production-like dependencies. The approach requires inspecting project-specific routes, fixtures, and cleanup rules to ensure isolated, deterministic test coverage.

What is the best way to test authentication boundaries in production-like conditions?

Testing authentication boundaries in production-like conditions requires exercising public interfaces the same way a real caller would. You validate success paths, input errors, and authorization failures using real persistence with isolated test data.

Can I use this approach to test CLI and queue workflows, not just HTTP endpoints?

Yes, this end-to-end testing approach applies to CLI, queue, and RPC service workflows. It verifies real user-facing behavior through the application's public interfaces, ensuring changes to any user-facing workflow maintain reliable coverage.

How do I handle test data cleanup and fixtures for deterministic end-to-end tests?

To ensure deterministic end-to-end tests, you derive cleanup rules and fixtures from the repository's existing test setup. This project-specific inspection preserves isolated test coverage by validating persistence effects without leaving residual data.

Why does my end-to-end test fail when relying on internal implementation details?

End-to-end tests fail when relying on internal implementation details because they should verify behavior through public interfaces. By exercising public contracts like real callers, tests remain stable and reliable against internal refactoring.