- Home
- Skills
- Velcrafting
- Codex Skills
- Backend Test Additions
backend-test-additions_skill
- Python
1
GitHub Stars
1
Bundled Files
3 weeks ago
Catalog Refreshed
2 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstart where the catalogue uses aiagentskills.
npx veilstart add skill velcrafting/codex-skills --skill backend-test-additions- SKILL.md2.4 KB
Overview
This skill helps add or extend backend tests to prove domain invariants, endpoint behavior, job semantics, and adapter parsing/failure handling. It focuses on deterministic, high-signal tests that reduce flakiness while documenting coverage and outcomes. The goal is small, targeted additions that validate behavior and prevent regressions.
How this skill works
You provide the target module, the acceptance criteria to validate, the repo's existing test conventions, and the preferred mocking strategy. The skill selects the most valuable test layer (unit, integration, or contract) with the lowest risk of flakiness, defines a minimal test set (happy path plus at least two failure cases), and generates test files, fixtures, and small helper utilities consistent with repo norms. It also logs telemetry about test type, failure paths covered, files changed, and outcome.
When to use it
- When a new endpoint, job, or adapter needs behavior guarantees before release
- When a bug fix requires regression tests to prevent reintroduction
- When domain invariants must be codified and enforced in tests
- When adding or changing retry/idempotency behavior for background jobs
- When adapter parsing or external failure handling needs explicit verification
Best practices
- Prefer the highest-value layer with the lowest flake risk (unit first, integration when boundary behavior matters)
- Always include a happy path plus at least two distinct failure paths (validation/auth/error mapping or external failure)
- Mock external systems at adapter boundaries; use test DBs if mocking persistence is not standard
- Keep tests deterministic: control randomness, freeze time where needed, and avoid sleep-based waits
- Make minimal code extractions only when necessary to enable focused testing
Example use cases
- Add unit tests for domain invariants to ensure business rules never regress
- Create integration tests verifying endpoint status/error codes and payload mapping
- Validate job idempotency and retry decisions with controlled failure injection
- Add contract tests that assert adapter parsing logic and graceful handling of malformed responses
- Replace a flaky end-to-end check with targeted adapter boundary tests and mocks
FAQ
A happy path plus at least two failure paths that matter to users or operators, such as validation errors, auth failures, or external dependency failures.
When should I mock persistence versus using a test DB?
Follow the repo's existing conventions: mock persistence if the project standard does so; otherwise prefer a test DB to exercise realistic integration behavior.