一键在 Manus 中运行任何 Skill

testing-craft

星标4

分支0

更新时间2026年7月7日 16:10

Testing standards — what to test, at which seam, and what makes a test worth having. Use whenever writing or reviewing tests for new behavior.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

ljojua1998

ljojua1998/skills

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Testing Craft

What a good test is

A good test reads like a specification of behavior and survives refactoring: it exercises a public seam (API endpoint, exported function/hook, component behavior, CLI) and asserts observable outcomes — not internals.

Where to test (choose the cheapest seam that gives a real signal)

Unit: pure logic — parsers, calculations, reducers, validators.
Integration: endpoint/service with real (or containerized/in-memory) DB — the default for backend behavior.
Component: render + interact + assert visible result (Testing Library style) — the default for frontend behavior.
E2E: only for the few critical user journeys; keep the suite small and stable.

Minimum coverage for new behavior

Happy path with realistic data.
One boundary/edge case that matters (empty, max, unicode, zero).
Failure path: invalid input rejected with the right error; authz denied for another user's resource (backend); error state rendered (frontend).

Anti-patterns (a reviewer will flag these as findings)

Tautological assertions — recomputing the expected value with the same code path under test.
Mocking the thing under test or mocking internals so deeply the test asserts the mock, not the behavior.
Tests coupled to implementation details (private method calls, CSS class names, exact log strings) that break on any refactor.
Asserting nothing (expect(result).toBeDefined() as the only assertion).
Sleeping/arbitrary timeouts instead of awaiting a deterministic signal — flaky by design.
Deleting or skipping a failing test to make the suite green.

Discipline

Run the whole relevant suite before declaring done, not only your new tests.
Regression tests for bug fixes are written to fail on the bug first, then pass with the fix.
Follow the project's existing test framework, helpers, and naming — don't introduce a second stack.

同仓库更多 Skills

同仓库

database-craft

ljojua1998/skills

Database engineering standards for PostgreSQL, MySQL, MongoDB, Supabase and Firebase/Firestore — schema/index design, security, and the per-engine gotchas an agent gets wrong. Loaded on top of backend-craft when a ticket touches the database. Use when designing schema, queries, migrations or data-access.

2026-07-104

nextjs-craft

ljojua1998/skills

Next.js App Router full-stack standards — server/client boundaries, the four caching layers, server-action security, route handlers, rendering/streaming, metadata, middleware limits, and Next-specific testing. Loaded on top of react-craft (and alongside backend-craft for server code) when the ticket's stack is Next.js. Use when building any Next.js route, action, or API surface.

2026-07-104

qa-tooling-craft

ljojua1998/skills

Headless QA tooling for driving real test tools from the CLI — Postman/Newman (functional + contract), OWASP ZAP + nuclei (security/DAST, the agent-drivable substitute for Burp), and k6/JMeter/autocannon (load). Use when running a comprehensive QA/security/load sweep against a running app.

2026-07-104

ship

ljojua1998/skills

Full delivery pipeline — takes a feature/project request, plans it into Jira-like markdown tickets, builds each ticket with specialized developer agents, then runs QA, security and code-audit agents, loops a debugger agent over findings until clean, and closes with a final report. Use when the user asks to build a feature or project end-to-end, or invokes /ship.

2026-07-104

express-craft

ljojua1998/skills

Express.js (Node) engineering standards — layering, async error handling (Express 4 vs 5), boundary validation, security middleware, graceful shutdown, and testing. Loaded on top of backend-craft when the ticket's stack is Express. Use when building Express APIs.

2026-07-104

nestjs-craft

ljojua1998/skills

NestJS engineering standards — feature-module architecture, DI discipline, DTO validation, the guard/interceptor/pipe/filter split, config, TypeORM/Prisma, and testing. Loaded on top of backend-craft when the ticket's stack is NestJS. Use when building NestJS APIs.

2026-07-104

Testing Craft

What a good test is

Where to test (choose the cheapest seam that gives a real signal)

Unit: pure logic — parsers, calculations, reducers, validators.

Integration: endpoint/service with real (or containerized/in-memory) DB — the default for backend behavior.

Component: render + interact + assert visible result (Testing Library style) — the default for frontend behavior.

E2E: only for the few critical user journeys; keep the suite small and stable.

Minimum coverage for new behavior

Happy path with realistic data.

One boundary/edge case that matters (empty, max, unicode, zero).

Failure path: invalid input rejected with the right error; authz denied for another user's resource (backend); error state rendered (frontend).

Anti-patterns (a reviewer will flag these as findings)

Tautological assertions — recomputing the expected value with the same code path under test.

Mocking the thing under test or mocking internals so deeply the test asserts the mock, not the behavior.

Tests coupled to implementation details (private method calls, CSS class names, exact log strings) that break on any refactor.

Asserting nothing (expect(result).toBeDefined() as the only assertion).

Sleeping/arbitrary timeouts instead of awaiting a deterministic signal — flaky by design.

Deleting or skipping a failing test to make the suite green.

Discipline

Run the whole relevant suite before declaring done, not only your new tests.

Regression tests for bug fixes are written to fail on the bug first, then pass with the fix.

Follow the project's existing test framework, helpers, and naming — don't introduce a second stack.

name	testing-craft
description	Testing standards — what to test, at which seam, and what makes a test worth having. Use whenever writing or reviewing tests for new behavior.
user-invocable	false