backend-test-additions_skill

This skill helps you add focused backend tests to verify invariants, endpoint behavior, and retries across services.
  • 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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
backend-test-additions skill by velcrafting/codex-skills | VeilStrat