# Backend Test Additions

> Add or extend backend tests to prove behavior, invariants, and regressions for services/endpoints/jobs.

- Skill: `velcrafting/backend-test-additions` (Agent Skill)
- Install (CLI): `npx skillmds@latest add velcrafting/backend-test-additions`
- Raw SKILL.md: https://api.skillmd.com/api/skills/velcrafting/backend-test-additions/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: velcrafting (https://skillmd.com/u/velcrafting)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/velcrafting/backend-test-additions

---


# Skill: backend/backend-test-additions

## Purpose
Add backend tests that prove:
- domain invariants
- endpoint behavior and error mapping
- job behavior (idempotency/retries) where applicable
- integration adapter parsing and failure handling

Prefer deterministic, high-signal tests.

---

## Inputs
- Target module/endpoint/job
- Behavior to validate (acceptance criteria)
- Existing test stack and conventions (from repo/profile)
- Mocking strategy (fixtures, fakes, contract tests) if present

---

## Outputs
- New or updated test files
- Supporting fixtures/mocks
- Optional helper utilities if consistent with repo norms

---

## Non-goals
- Adding a new test framework
- Snapshot-only testing unless repo standard
- Broad refactors just to “make it testable” (prefer small extraction)

---

## Workflow
1) Identify test layers available:
   - unit tests (domain)
   - integration tests (endpoint boundary)
   - contract tests (external adapters)
2) Choose the highest-value layer with lowest flake risk.
3) Define minimum test set (default):
   - happy path
   - at least two failure paths:
     - validation/auth/error mapping OR invariant violation OR external failure
4) Mock at boundaries:
   - external APIs mocked at adapter boundary
   - persistence mocked only if repo standard; otherwise use test DB
5) Keep tests deterministic:
   - avoid time-based waits when possible
   - control randomness, time, and ids
6) Run tests using repo commands.

---

## Checks
- Tests pass locally (or a deterministic alternative is documented)
- Coverage includes:
  - happy path
  - at least 2 failure paths
- Tests assert outcomes users/operators care about:
  - status codes, error codes, invariants, retry decisions
- Minimal flakiness risk

---

## Failure modes
- Test commands unknown → consult `REPO_PROFILE.json` or recommend `personalize-repo`.
- Flaky tests → stabilize by removing timing dependence and controlling mocks.
- Hard-to-test coupling → extract minimal module boundary and test there.

---

## Telemetry
Log:
- skill: `backend/backend-test-additions`
- test_type: `unit | integration | contract`
- failure_paths_covered: count
- files_touched
- outcome: `success | partial | blocked`