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.