testing-guidelines

Estrelas11

Forks4

Atualizado29 de julho de 2026 às 11:23

Opinionated language-agnostic test-admission and sans-I/O unit-testing rules. Use when proposing, writing, reviewing, or deleting tests; deciding whether behavior is project-owned; evaluating wrapper, schema, ORM, framework, mock, or third-party-library tests; or separating pure business policy from wiring and I/O.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

Casper-Studios

Casper-Studios/casper-marketplace

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·SOC 15-1253

Explorador de arquivos

6 arquivos

SKILL.md

readonly

name	testing-guidelines
description	Opinionated language-agnostic test-admission and sans-I/O unit-testing rules. Use when proposing, writing, reviewing, or deleting tests; deciding whether behavior is project-owned; evaluating wrapper, schema, ORM, framework, mock, or third-party-library tests; or separating pure business policy from wiring and I/O.
license	MPL-2.0
metadata	{"author":"Basti Ortiz <ortiz@bastidood.dev>","source":"https://github.com/BastiDood/skills"}

Testing Guidelines

This skill treats tests as protection for project-owned behavior, not as a coverage ritual. It favors cheap sans-I/O tests and rejects tests that merely restate third-party libraries or transparent wiring.

Test Admission

Test behavior that the project owns. Assume third-party libraries are correct and already tested.

Add a test only when it can fail because project-owned behavior is wrong.

Project-owned behavior includes:

Business rules and calculations.
State-machine transitions and exhaustive decisions.
Transformations that add domain meaning.
Selection, retry, fallback, caching, and persistence policy.
Error translation that adds a stable project contract.

Do not add a test when the implementation only forwards values to a dependency and returns its result unchanged.

Existing-Test Review

Delete a test when it only:

Repeats third-party documentation.
Asserts schema-library mechanics.
Verifies a one-to-one forwarding wrapper.
Asserts mock configuration.
Checks getters, constructors, or field assignment without behavior.
Exercises framework plumbing without a project-owned contract.

Do not preserve a useless test for coverage. Coverage is evidence of execution, not evidence of meaningful verification.

References

Read as many linked references as are relevant to the current task before writing, approving, or retaining tests.

Do not claim ownership of documented library behavior; treat third-party dependencies as already verified.
Exclude tests that only prove delegation through transparent wrappers.
Prove project-owned policy through cheap sans-I/O tests, adding wiring coverage only for owned boundary behavior.

Mais deste repositório

mesmo repositório

agent-skills-best-practices

Casper-Studios/casper-marketplace

Opinionated conventions for authoring, restructuring, and reviewing agent skills. Use when deciding whether guidance belongs in `SKILL.md`, a conditional reference, or a smaller skill; writing trigger descriptions and reference routers; naming procedural or documentary skills; creating examples; keeping skill context focused; or bundling static assets and their licenses.

2026-07-2911

plugin-best-practices

Casper-Studios/casper-marketplace

Opinionated conventions for designing focused agent-skill plugins as encapsulated, installable capabilities. Use when defining a plugin boundary, deciding which skills are public entry points, hiding shared implementation skills, splitting broad plugins, designing plugin structure, minimizing client manifests, or removing auxiliary package documentation.

2026-07-2911

code-style

Casper-Studios/casper-marketplace

Opinionated language-agnostic design rules for implementation, refactoring, and code review. Use when shaping conditional control flow, finite states, invariants, error boundaries, resource lifetimes, abstractions, public APIs, validation boundaries, pagination, missing values, or the separation of sans-I/O decisions from imperative drivers.

2026-07-2911

vertically-sliced-feature-modules

Casper-Studios/casper-marketplace

Opinionated feature-first architecture conventions for cohesive modules, owned subtrees, entry points, shared-code promotion, and package boundaries. Use when designing or reviewing directory structure, placing UI or workflow code, splitting nested capabilities, extracting shared modules, enforcing feature import boundaries, deciding whether a feature deserves a package, or refactoring horizontal technical layers.

2026-07-2911

better-all-best-practices

Casper-Studios/casper-marketplace

Opinionated `better-all` conventions for dependency-declared async task graphs, inferred task results, cancellation propagation, and failure semantics. Use when replacing serial `await` chains or manual `Promise.all` stages, parallelizing work with result dependencies, or writing and reviewing `all` and `allSettled` task definitions.

2026-07-2911

open-telemetry-best-practices

Casper-Studios/casper-marketplace

Opinionated logging and error-handling conventions for OpenTelemetry-compatible systems covering log levels, attribute naming, and error classification. Use when writing log statements, choosing log levels, or handling errors with traces.

2026-07-2911

name	testing-guidelines
description	Opinionated language-agnostic test-admission and sans-I/O unit-testing rules. Use when proposing, writing, reviewing, or deleting tests; deciding whether behavior is project-owned; evaluating wrapper, schema, ORM, framework, mock, or third-party-library tests; or separating pure business policy from wiring and I/O.
license	MPL-2.0
metadata	{"author":"Basti Ortiz <ortiz@bastidood.dev>","source":"https://github.com/BastiDood/skills"}

Testing Guidelines

Test Admission

Test behavior that the project owns. Assume third-party libraries are correct and already tested.

Add a test only when it can fail because project-owned behavior is wrong.

Project-owned behavior includes:

Business rules and calculations.
State-machine transitions and exhaustive decisions.
Transformations that add domain meaning.
Selection, retry, fallback, caching, and persistence policy.
Error translation that adds a stable project contract.

Do not add a test when the implementation only forwards values to a dependency and returns its result unchanged.

Existing-Test Review

Delete a test when it only:

Repeats third-party documentation.
Asserts schema-library mechanics.
Verifies a one-to-one forwarding wrapper.
Asserts mock configuration.
Checks getters, constructors, or field assignment without behavior.
Exercises framework plumbing without a project-owned contract.

Do not preserve a useless test for coverage. Coverage is evidence of execution, not evidence of meaningful verification.

References

Read as many linked references as are relevant to the current task before writing, approving, or retaining tests.

Do not claim ownership of documented library behavior; treat third-party dependencies as already verified.
Exclude tests that only prove delegation through transparent wrappers.
Prove project-owned policy through cheap sans-I/O tests, adding wiring coverage only for owned boundary behavior.