ワンクリックでManusで任意のスキルを実行

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 リポジトリを開く Creator のリポジトリを見る

ダウンロード

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