# Test Backend Services

> Design and implement backend tests (unit, integration) for services and HTTP endpoints with clear acceptance criteria.

- Skill: `willyu1007/test-backend-services` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds add willyu1007/test-backend-services`
- Raw SKILL.md: https://api.skillmd.com/api/skills/willyu1007/test-backend-services/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: willyu1007 (https://skillmd.com/u/willyu1007)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/willyu1007/test-backend-services

---


# Test Backend Services

## Purpose
Provide a practical testing strategy for backend services that balances confidence, speed, and maintainability.

## When to use
Use this skill when you are:
- Adding a new service method or business rule
- Adding or modifying an endpoint
- Fixing regressions and adding coverage
- Introducing test fixtures, factories, or test data builders

## Inputs
- Business rules and expected outcomes
- Endpoint contract (if testing HTTP)
- Persistence requirements (if integration tests verify DB side effects)
- Existing testing framework and conventions

## Outputs
- A test plan (unit + integration) with acceptance criteria
- Unit tests for service logic (mocked dependencies)
- Integration tests for HTTP behavior (optional but recommended)

## Rules
- Business rules MUST be covered by unit tests at the service layer.
- Integration tests SHOULD cover at least one happy-path request for each new endpoint.
- Tests MUST be deterministic and isolated (no reliance on external shared state).
- Tests MUST NOT require real credentials.

## Recommended test pyramid
1. **Unit tests**
   - fast
   - focus on business logic
   - dependencies mocked

2. **Integration tests**
   - verify wiring and persistence
   - run against an isolated DB (ephemeral or test container)

3. **End-to-end tests**
   - optional
   - use sparingly for critical flows

## Steps
1. Identify critical behaviors and failure modes.
2. Write service unit tests first:
   - success path
   - one representative domain error (e.g., conflict)
3. Add endpoint integration test (when applicable):
   - request validation and response shape
   - database side effects (if any)
4. Add fixtures/builders to reduce boilerplate.
5. Verify tests run reliably in CI.

## Verification

- [ ] Unit tests pass with mocked dependencies (no real DB/network)
- [ ] Integration tests pass against an isolated test database
- [ ] Tests are deterministic (no flaky failures)
- [ ] Tests run successfully in CI environment
- [ ] Business rules have corresponding unit tests
- [ ] At least one happy-path integration test exists for each endpoint

## Boundaries

- MUST NOT use real credentials in tests
- MUST NOT depend on shared external state (tests must be isolated)
- MUST NOT skip test cleanup (reset DB state between tests)
- MUST NOT test implementation details (test behavior, not internals)
- SHOULD NOT mock everything (integration tests need real wiring)
- SHOULD NOT write end-to-end tests for every scenario (use sparingly)

## Included assets
- Templates: `./templates/` includes unit and integration test scaffolds.
- Examples: `./examples/` includes a service unit test example.