write-api-e2e-tests

Write API end-to-end tests following ADR-defined suite architecture and conventions.

3.4k|728|Updated Jun 28, 2022
One-click install
npx skills add https://github.com/linuxfoundation/crowd.dev --skill write-api-e2e-tests
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: write-api-e2e-tests
Source: https://github.com/linuxfoundation/crowd.dev/tree/main/.claude/skills/write-api-e2e-tests
Command: npx skills add https://github.com/linuxfoundation/crowd.dev --skill write-api-e2e-tests

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Adding or changing API endpoints without end-to-end coverage leaves critical API behaviour untested, and writing tests without following the project's established architecture creates inconsistent, unmaintainable suites.

Core Features & Use Cases

  • Guided e2e test authoring: Writes or extends API end-to-end tests aligned with ADR-0012 (runtime, isolation, scope) and ADR-0013 (suite organisation, helpers, conventions).
  • Suite execution workflow: Runs the affected suite via the public-api-e2e-tests.sh entrypoint and iterates until tests pass.
  • Scope guardrails: Distinguishes API e2e testing from unit tests and avoids seeding databases directly, preferring API-created fixtures.
  • Use Case: After adding a new Public API endpoint, use this Skill to add a contract test to the existing suite, run it locally, and document any coverage gaps.

Quick Start

Write an end-to-end test for the new Public API endpoint I just added and run the e2e suite to verify it passes.

Frequently Asked Questions about write-api-e2e-tests

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

FAQPage Schema
How do I write API end-to-end tests for a new endpoint?

Identify the API surface (defaulting to the Public API), read ADR-0012 and ADR-0013 for architecture and conventions, then add or extend the appropriate suite. Run the affected suite locally with the public-api-e2e-tests.sh entrypoint and fix failures until green.

How do I run the API e2e test suite locally?

Export the environment variables required by the suite entrypoint, then run bash .github/scripts/public-api-e2e-tests.sh. Refer to ADR-0012 and the entrypoint script for environment setup, reset behaviour, and local development workflows.

When should I use e2e tests instead of unit tests?

Use API e2e tests for observable API behaviour, smoke, and contract coverage of endpoints. Use unit tests instead for domain logic or SQL correctness, and avoid e2e tests for Temporal, OpenSearch, or other eventual side effects outside the documented scope.

Can I seed the database directly for e2e test fixtures?

No, fixtures should be created through the API whenever possible. If required fixtures cannot be created via the API, test the supported scenarios and explain the coverage gaps rather than seeding the database directly.

What are the limitations of this API e2e testing approach?

The approach is limited to observable API behaviour within the documented scope and does not cover eventual side effects in systems like Temporal or OpenSearch. It also does not support creating a new testing framework or suite style outside the ADR-defined conventions.